1. トークンバケットアルゴリズム
アルゴリズムのアイデアは次のとおりです。
トークンは固定レートで生成され、トークン バケットにキャッシュされます。
トークン バケットがいっぱいになると、余分なトークンは破棄されます。
リクエストは処理されるために比例トークンを消費する必要があります。
トークンが足りない場合、リクエストはキャッシュされます。
2. リーキーバケットアルゴリズム
アルゴリズムのアイデアは次のとおりです。
水（要求された）はバケツの上から注がれ、バケツの下から流れ出ます（処理されます）。
流出し遅れた水はバケツ（バッファ）に貯められ、一定の速度で流出します。
バケツがいっぱいになると水が溢れます（捨てる）。
このアルゴリズムの核心は、リクエストをキャッシュし、均一な速度で処理し、冗長なリクエストを直接破棄することです。
リーキー バケット アルゴリズムと比較すると、トークン バケット アルゴリズムは「バケット」だけでなく、トークンを格納するために使用されるバケットと、リクエストを格納するために使用されるキューも持つ点が異なります。
リーキーバケットアルゴリズムとトークンバケットアルゴリズムの機能面での最も明らかな違いは、バーストトラフィック（バースト）の処理を許可するかどうかであり、リーキーバケットアルゴリズムはデータのリアルタイム送信（処理）速度を強制的に制限することができます。 、追加の取引は行いません。
トークン バケット アルゴリズムでは、データの平均送信速度を制限しながら、ある程度のバースト送信を許可できます。
Nginx のリクエスト レート別速度制限モジュールは、リーキー バケット アルゴリズムを使用しており、リクエストのリアルタイム処理速度が設定されたしきい値を超えないことを強制的に保証できます。
3. 構成例
1、リミットコンゾーン
1.1 nginxの設定
http{
limit_conn_zone $binary_remote_addr zone=one:10m;
server
{
......
limit_conn one 10;
......
}
}
このうち「limit_conn one 10」は、サーバー層に配置してサーバー全体に有効にすることも、ロケーションに配置して単一のロケーションにのみ有効にすることもできます。この構成は、クライアントの同時接続数が 10 までであることを示しています。
1.2 結果
ab ツールは 20 個の nginx を同時にリクエストし、完全なリクエスト: 20 失敗したリクエスト: 9 を確認できます (nginx 構成の IP への同時接続数が 10 で、結果の成功数が +1 であるため)カウンタは 0 から始まるので、もう 1 つになります。nginx ログでは、503 を返すリクエストが 9 件あることもわかります）
2、limit_req_zone
2.1 nginxの設定
http{
limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s;
server
{
......
limit_req zone=req_one burst=120;
......
}
}
このうち、「limit_reqzone=req_oneburst=120」は、サーバー層に配置してサーバー全体に有効にすることも、ロケーションに配置して単一のロケーションにのみ有効にすることもできます。
rate=1r/s は、各アドレスが 1 秒あたり 1 回のみリクエストできることを意味します。つまり、トークン バケット Burst=120 には合計 120 個のトークンがあり、新しいトークンは 1 秒あたり 1 つだけ追加され、120 個のトークンが送信された後、追加のリクエストは 503 を返します。
3、ngx_http_upstream_module
3.1 公式文書の導入により、
このモジュールにはパラメータがあります: max_conns はサーバーのフローを制限できますが、残念ながらこれは nginx の商用バージョンでのみ使用できます。ただし、nginx1.11.5 バージョン以降、公式はこのパラメータを商用バージョンから分離しました。つまり、運用環境で広く使用されている nginx1.9.12 および 1.10 バージョンをアップグレードする限り、このパラメータを使用できます (テストを通じて、が表示されます。古いバージョンの nginx では、このパラメータを追加すると nginx サービスを開始できなくなります。
3.2 構成
upstream xxxx{
server 127.0.0.1:8080 max_conns=10;
server 127.0.0.1:8081 max_conns=10;
}
3.3 結果
2 台のマシンを使用して、ab ツールを使用して 20、30、および 40 の同時リクエストを nginx に送信します。同時リクエストの数に関係なく、成功したリクエストは 12 件のみで、成功したリクエストの数はさらに 2 件増えることがわかります。同時に、1.2のテスト結果は成功です。回数も *+1* です。ここでは 2 台のマシンがあり、この考察に基づいてマシンの数を 3 台に増やし、成功数は 13です。
これは仮説です。クライアントの *+1 に応じて、成功したリクエストの数は +1*になります(これは単なる仮定です)** 注: 非常に重要な点がまだあります。max_conns はすべてではなく、アップストリームの 1 つのサーバーに対するものです。nginx には worker_processes というパラメータがあり、max_conns は各 worker_processes に対するものです。