[高同時実行性] 数十億のトラフィック下で分散電流制限を実現するにはどうすればよいでしょうか?これらの理論をマスターしなければなりません! ！

[[335435]]

著者は、正確にスケジュールされたタスクと遅延キュー処理機能を備えた、高同時実行シナリオ向けのシンプルで安定したスケーラブルな遅延メッセージ キュー フレームワークを個人的に開発しました。半年以上前にオープンソース化されて以来、10 社を超える中小企業に正確でタイムリーなスケジューリング ソリューションを提供することに成功し、実稼働環境でのテストにも耐えてきました。より多くの人々の利益のために、オープンソース フレームワークのアドレスが次のように提供されます。

https://github.com/sunshinelyz/mykit-delay

PS: ソース コードにスターを付けていただくことも歓迎します。また、素晴らしいコードを PR することもできます。

序文

インターネット アプリケーションでは、高同時実行システムは、Tmall の Double Eleven、JD.com の 618、フラッシュ セール、ラッシュ購入プロモーションなど、大量の高同時実行アクセスという大きな課題に直面しています。これらは、典型的な高トラフィックおよび高同時実行のシナリオです。

注: 元の記事はかなり長いため、理論、アルゴリズム、実践 (HTTP インターフェースの実践 + 分散電流制限の実践) の 3 つの部分に分かれています。

高同時実行システムの電流制限

短期間で大量のアクセストラフィックが発生する場合、システム自体の安定性を確保しながら、高い同時実行性を処理できるようにするにはどうすればよいでしょうか。私のシステムは分散型なので、問題を解決するにはマシンを追加するだけで十分だと言う人もいるでしょう。しかし、マシンを追加しても問題が解決しない場合はどうすればよいでしょうか?この場合、マシンを無期限に追加することはできません。サーバーのハードウェア リソースは常に制限されています。リソースが限られている中で、このような高トラフィックおよび高同時アクセスに対処するには、キャッシュ、非同期、劣化、電流制限、静的化など、バックエンド サービス システムを保護するための他の対策を講じる必要があります。

ここでは、まず電流制限の実装方法について説明します。

電流制限とは何ですか?

高同時実行システムでは、電流制限とは通常、システムを保護するために、高同時実行アクセスまたはリクエストの速度を制限すること、または一定期間内のリクエストの速度を制限することを指します。システムの速度制限ルール (システムによって制限される要求速度など) に達すると、これらの要求は次の方法で処理されます。

• サービス拒否 (フレンドリーなプロンプトまたはエラー ページへのジャンプ)。
• 列に並ぶか待つ（フラッシュセールシステムなど）。
• サービスの低下（デフォルトのフォールバック データに戻ります）。

実際、これは 10r/s などのリクエストの速度を制限するもので、つまり 1 秒あたり 10 件のリクエストのみが許可され、リクエストの速度が制限されます。ある意味では、電流制限は実際には特定の周波数での量を制限することです。

電流制限は一般的に、システム サービス要求のレートを制御するために使用されます。たとえば、Tmall Double Eleven 電流制限、JD 618 電流制限、12306 チケット取得などです。

電流制限の使用シナリオは何ですか?

ここで、例を見てみましょう。ショッピングモールシステムを作ったとします。休日中に、注文を送信するためのインターフェースへのリクエスト数が通常時に比べて 50 倍近く増加していることに突然気付きました。すぐに注文を送信するためのインターフェースがタイムアウトし、例外がスローされ、ほとんど使用できなくなります。さらに、注文インターフェースがタイムアウトして利用できなくなったため、他のシステム サービスも失敗しました。

このような高トラフィックのシナリオにはどのように対処すればよいでしょうか?一般的な解決策は、フローを制限することです。もちろん、電流制限に加えて、他の解決策もあります。この記事では主に電流制限について説明します。

• 希少資源のフラッシュセールおよび急ぎの購入。
• 注文の送信、大量のデータのデータベースへの即時挿入など、データベースに対する高度な同時読み取りおよび書き込み操作。

電流制限は、同時実行性の高い問題に対処するための強力なツールであると言えます。電流制限により、瞬間的なピーク トラフィックによるシステム サービスの圧迫やサービス ダミーの発生を心配する必要がなくなり、最終的にはサービスがまったく提供されないのではなく、損失のあるサービスが提供されます。