一般的に使用される 4 つの電流制限アルゴリズムをマスターすれば、必ず面接に合格できます

EC プロモーションなどの同時アクセスが多い環境では、トラフィックが流入し続け、サービス間の相互呼び出しの頻度が急激に増加し、システムの負荷が高くなりすぎます。システムが依存するサービスの安定性はシステムに大きな影響を与え、ネットワーク接続の中断やサービスのダウンタイムなど、雪崩を引き起こす可能性のある不確実な要因が数多くあります。一般に、マイクロサービスのフォールト トレラント コンポーネントは、電流制限、絶縁、劣化、回路ブレーカーなどの手段を提供し、マイクロサービス システムを効果的に保護します。この記事では主に電流制限について説明します。

電流制限とは、動作周波数が定義された制限を超えないように最大流量 を制限することを意味します。システムが提供できる最大同時実行数には制限があり、同時にリクエストが多すぎるため、フラッシュ セールや大規模なプロモーションなどのスロットリングが必要になります。大量のリクエストが瞬時に殺到すると、サーバーはそれに対応できなくなります。したがって、スロットリングする必要があります。レート制限は、一定期間内に API に到達できるリクエストの数を制限することで、サービスを偶発的または悪意のある過剰使用から保護します。レート制限がないと、どのユーザーもサーバーにリクエストを大量に送信し、他のユーザーが餓死する状況を引き起こす可能性があります。

なぜ速度制限があるのですか?

• リソース枯渇の防止: レート制限の最も一般的な理由は、リソース枯渇を回避して API ベースのサービスの可用性を高めることです。レート制限を適用すると、負荷ベースのサービス拒否 (DoS) 攻撃を防ぐことができます。たとえ 1 人のユーザーが大量のリクエストを API に浴びせたとしても、他のユーザーが飢えることはありません。
• セキュリティ: レート制限により、ログインやプロモーション コードなどのセキュリティ重視の機能に対するブルート フォース攻撃を防止します。これらの関数に対するリクエストの数はユーザー レベルで制限されているため、これらのシナリオではブルート フォース アルゴリズムは機能しません。
• 運用コストの防止: 従量課金モデルでのリソースの自動拡張の場合、レート制限は仮想上限を設定することで運用コストの制御に役立ちます。リソース拡張の制限。レート制限を行わないと、リソースが不釣り合いに拡張され、請求額が急激に増加する可能性があります。

レート制限ポリシー レート制限は次のパラメータに適用できます:

• User: 指定された時間に制限します。 period ユーザーに許可されるリクエストの数。ユーザーベースのレート制限は、レート制限の最も一般的で直感的な形式の 1 つです。
• 同時実行数 : これにより、特定の時間枠内でユーザーが許可できる並列セッションの数が制限されます。並列接続の数を制限すると、DDOS 攻撃の軽減にも役立ちます。
• 場所/ID: これは、場所ベースまたは人口統計に焦点を当てたキャンペーンを実行する場合に便利です。ターゲット層からのリクエスト以外のリクエストは、ターゲット領域での可用性を高めるために調整できます。
• サーバー: サーバーベースのレート制限は、ニッチな戦略です。これは通常、特定のサーバーがリクエストの大部分を必要とする場合、つまりサーバーが特定の機能に強く結合されている場合に使用されます

##次に、4 つの一般的な電流制限アルゴリズムを紹介します

1. リーキーバケットアルゴリズム

リーキーバケットアルゴリズムのアイデアは、

シンプルで直感的なアルゴリズムです。水滴を流出させる固定容量のリーキーバケットです。一定の固定レートで。バケツが空の場合は、水滴を流す必要はありません。漏れのあるバケツには、どのような場合でも水が流入する可能性があります。流入する水滴がバケツの容量を超える場合、流入する水滴はオーバーフロー（廃棄）されますが、漏れのあるバケツの容量は変化しません。

このアルゴリズムの利点は、リクエストのバーストを平滑化し、一定の速度で処理できることです。ロード バランサーへの実装も簡単で、すべてのユーザーにとってメモリ効率が高くなります。リクエストの数に関係なく、サーバーへの一定のほぼ均一なトラフィックを維持します。

欠点は、リクエストのバーストによってバケットがいっぱいになり、新しいリクエストが枯渇する可能性があることです。また、リクエストが指定された時間内に完了することも保証されません。

利点:

• スムーズな交通。 リーキー バケット アルゴリズムはリクエストを固定レートで処理するため、トラフィックを効果的に平滑化および整形し、トラフィックのバーストや変動を回避できます (メッセージ キューの山を削り、谷を埋める機能と同様)。
• 過負荷を防ぎます。 受信リクエストがバケットの容量を超える場合、システムの過負荷を防ぐためにリクエストを直接破棄できます。

欠点:

• バースト トラフィックを処理できません: リーキー バケットのエクスポート速度は固定されているため、バースト トラフィックを処理できません。たとえば、トラフィックが少ない場合でもリクエストをより速く処理することはできません。
• データが失われる可能性があります: インレット トラフィックが大きすぎてバケットの容量を超える場合、一部のリクエストを処理する必要があります。捨てられた。これは、リクエストの欠落が許容できない一部のシナリオでは問題になる可能性があります。

2. トークン バケット アルゴリズム

トークン バケット アルゴリズム: 制限が 2r/s であると仮定すると、バケットは次の時点でバケットに送信されます。 500 ミリ秒の固定レート。トークンを に追加します。バケットには最大 b 個のトークンを保存でき、バケットがいっぱいになると、新しく追加されたトークンは破棄または拒否されます。サイズ n バイトのパケットが到着すると、バケットから n 個のトークンが削除され、パケットがネットワークに送信されます。バケット内のトークンが n 個未満の場合、トークンは削除されず、パケットはフロー制限されます (破棄またはバッファリングのいずれか)。トークンバケットの電流制限原理は図に示すとおりです。

#電流制限サーバー側のトークン バケットは、実際のトークンの生成速度とバケットの容量を調整できます。サービス実績と期間です。レートを上げる必要がある場合は、バケットに入れるトークンのレートを必要に応じて増やすことができます。

トークンの生成速度は一定ですが、トークンの要求速度は制限されません。これは、瞬間的な大規模なトラフィックに直面した場合、アルゴリズムが短時間で大量のトークンを取得でき、トークンを取得するプロセスで多くのリソースが消費されないことを意味します。新しいリクエスト サーバーに到達すると、2 つの操作が実行されます:

Get token

: このユーザーの現在のトークン数を取得します。定義された制限より大きい場合、リクエストはドロップされます。
• Update token
: 取得したトークンが期間制限 d 未満の場合、リクエストを受け入れてトークンを添付します。
• #このアルゴリズムは、アプリケーションのユーザーごとに保存されるデータ量が少ないため、メモリ効率が高くなります。ここでの問題は、分散環境で競合状態が発生する可能性があることです。これは、2 つの異なるアプリケーション サーバーからの 2 つのリクエストが同時にトークンを取得しようとした場合に発生します。

利点:

バースト トラフィックを処理できます。

• : トークン バケット アルゴリズムはバースト トラフィックを処理できます。バケットがいっぱいになると、リクエストは最大速度で処理されます。これは、バースト的なトラフィックを処理する必要があるアプリケーション シナリオに非常に役立ちます。 平均レートの制限
• : 長期運用では、データ送信レートは事前に定義された平均レートに制限されます (つまり、カードのコマンドレート）。 柔軟性
• : リーキー バケット アルゴリズムと比較して、トークン バケット アルゴリズムはより高い柔軟性を提供します。たとえば、トークンの生成レートは動的に調整できます。 欠点:

オーバーロードが発生する可能性がある

• : トークンの生成が速すぎると、オーバーロードが発生する可能性があります。その結果、トラフィックが大量にバーストし、ネットワークやサービスに過負荷がかかる可能性があります。 ストレージ スペースが必要です
• : トークン バケットには、トークンを保存するために一定量のストレージ スペースが必要です。これにより、メモリ リソースが無駄になる可能性があります。 。 実装は少し複雑です
• : カウンタ アルゴリズムと比較して、トークン バケット アルゴリズムの実装は少し複雑です。 3. 固定時間ウィンドウ アルゴリズム
固定時間ウィンドウでは、一定数のリクエストの入力が許可されます。数量を超過した場合、拒否されるか、次の期間を待つためにキューに入れられます。このカウンタ電流制限は、時間間隔内で制限することによって実装されます。ユーザーが前の間隔の終了前にリクエストを送信し (ただし、制限を超えていない)、現在の間隔の開始時にもリクエストを送信した場合 (これも制限を超えていない)、これらのリクエストはユーザーにとっては正常です。それぞれの間隔。ただし、時間間隔の重要な期間にリクエストがシステム制限を超えると、システムの過負荷が発生する可能性があります

カウンター アルゴリズムにはタイム クリティカル ポイントの欠陥があるため、タイム クリティカル ポイント付近の非常に短期間の攻撃に対して脆弱です。たとえば、インターフェイスに対して 1 分あたり最大 100 リクエストを設定できます。たとえば、12:00:00 ～ 12:00:59 の時間帯にはデータ リクエストはありませんが、時間帯に突然の同時リクエストが発生したとします。 12:00:59 ～ 12:01:00 の期間。100 件のリクエストがあり、次のカウント サイクルに入るとカウンタがクリアされ、12:01:00 ～ 12:01:01 の間に 100 件のリクエストがあります。つまり、タイムクリティカルポイントの前後では、同時にしきい値の2倍のリクエストが発生し、バックグラウンド処理リクエストの過負荷が発生し、システムの動作能力が不十分になり、場合によってはシステムがクラッシュする可能性があります。

欠点:

• 電流制限は十分に滑らかではありません。例: 現在の制限は 1 秒あたり 3 件で、最初のミリ秒間に 3 つのリクエストが送信されます。現在の制限に達すると、ウィンドウの残り時間内のすべてのリクエストが拒否され、エクスペリエンスが低下します。
• #ウィンドウ境界の問題を処理できません。フロー制御は特定の時間ウィンドウ内で実行されるため、ウィンドウ境界効果が発生する可能性があります。つまり、時間ウィンドウの境界で多数のリクエストの通過が許可され、バースト トラフィックが発生する可能性があります。

例: 現在の制限は 1 秒あたり 3 で、最初の 1 秒間の最後のミリ秒で 3 つのリクエストが送信され、最初の 1 ミリ秒で別のリクエストが送信されました。 2 番目、3 件のリクエスト。この 2 ミリメートル以内に 6 つのリクエストが処理されましたが、現在の制限はトリガーされませんでした。トラフィックのバーストが発生すると、サーバーに負荷がかかる可能性があります。

4. スライディング タイム ウィンドウ アルゴリズム

スライディング ウィンドウ アルゴリズムは、一定の期間を分割し、時間とともに移動させます。開始時点は時間リストになります。2 番目の時点では、一定の期間を分割し、時間とともに移動します。 、終了時点を１時点ずつ増やして連続的に繰り返すことで、カウンターの臨界点の問題を巧みに回避することができる。

スライディング ウィンドウ アルゴリズムは、カウンタ アルゴリズムにおける時間クリティカル ポイントの問題を効果的に回避できますが、時間セグメントの概念は依然として存在します。同時に、スライディング ウィンドウ アルゴリズムのカウント操作も、固定タイム ウィンドウ アルゴリズムよりも時間がかかります。

欠点: 電流制限の滑らかさが不十分であるという問題がまだあります。例: 現在の制限は 1 秒あたり 3 件で、最初のミリ秒間に 3 つのリクエストが送信されます。現在の制限に達すると、残りのウィンドウ時間内のすべてのリクエストが拒否され、エクスペリエンスが低下します。

概要

一般的に使用される 4 つの電流制限アルゴリズム、固定ウィンドウ アルゴリズム、スライディング ウィンドウ アルゴリズム、リーキー バケット アルゴリズム、およびトークン バケット アルゴリズムを紹介します。各アルゴリズムには独自の特徴と適用可能なシナリオがありますので、以下にそれらを簡単にまとめて比較してみましょう。

• トークン バケット アルゴリズム トラフィックの平滑化とバースト トラフィックの処理の両方が可能で、バースト トラフィックの処理が必要な状況に適しています。加工されるシーン。
• リーキー バケット アルゴリズム利点は、トラフィック処理がよりスムーズであることですが、バースト トラフィックには対処できないため、必要なシナリオに適しています。スムーズな交通。
• 固定ウィンドウ アルゴリズム は実装が簡単ですが、電流制限が十分に滑らかではなく、ウィンドウ境界の問題があります。電流制限の単純な実装が必要なシナリオ。
• スライディング ウィンドウ アルゴリズム はウィンドウ境界の問題を解決しますが、電流制限の滑らかさが不十分であるという問題がまだあります。平均リクエストレートを制御する必要があるアプリケーションシーン。

以上が一般的に使用される 4 つの電流制限アルゴリズムをマスターすれば、必ず面接に合格できますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。