Nginxのlimitモジュールによるストリーム制限

まず背景を話して、どうして限流をしますか?1つのシステムのスループットは通常QPSによって(TPS)、同時数の2つの要素は決定して、各システムのこの2つの値はすべて1つの相対的な限界値があって、適用シーンのアクセス圧力の下で、ある1つがシステムの最高値に達する限り、システムのスループットは上がらないで、もし圧力が引き続き増大するならば、システムのスループットはかえって下がることができて、原因はシステムの過負荷の仕事、コンテキストの切り替え、メモリなどのその他の消耗が招くのですシステムの性能が低下する.
つまり、同時性が高いほど、システムの処理能力が低くなり、TPSも低くなり、ユーザー体験にとって非常に友好的ではありません.同時性が高くなるにつれて、システムの処理能力が低くなり、応答時間が長くなり、多くのユーザーが空白のページの待機中にある可能性があります.そして、最もクラッシュしたのは、長い時間を待ってから、またタイムアウトしました.
このような状況に対応するには、我々のシステムの最適な処理能力(圧力測定の手段によって、どの程度の同時量のTPSが最も高いかを評価する)を評価し、その後、最適な処理能力に基づいて適切な限流操作を行う必要があります.それでは、我々のシステムが常に最適な同時量の処理状態にあることを保証し、さらに最高のTPSを保証する必要があります.最良の状態を超えたリクエストは彼に列を作ってもらい、ちょっと待って、列の長さを超えたら直接タイムアウトを教えてあげます!あとでやってみてください!
上記の要件に基づいて、Nginxのlimitモジュールが提供する能力を借りることができます.

//    http   
http{
        limit_req_zone all_request_limit_key zone=all_request_limit_config:10m rate=400r/s;
}

all_request_limit_key:自由に定義できます.つまり、limitモジュールはこのkeyをストリーム制限の根拠としています.こちらは全シーンのリクエストに対してストリーム制限を統一しています.異なるURlにストリーム制限をするには、複数のlimit_を構成することができます.req_zone. all_request_limit_config:勝手に定義できます.つまり、このlimitモジュールの変数名です.使用するとき、彼は唯一1つの構成10 mを識別します.limitモジュールは限流をするときもkeyなどの統計を保存しなければなりません.こちらはこの占有領域サイズrate=400 r/sを設定します.毎秒400個の要求を入れることができます.つまり、2.5 msごとに1つの要求を見逃すことができます.

//    location   
location / {
        limit_req zone=all_request_limit burst=2000;
        proxy_pass http://api.xxxxx.cn;
        proxy_set_header   Host             $http_host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_502 http_504;
}

burst=2000:キュー長が2000であることを示し、各リクエストが入ってきてもキューの中に並んでいることを示し、2.5 ms毎の速度で消費されている.キューがいっぱいになった状態であれば、後のリクエストは直接503に戻ることを拒否する.これはlocationに構成されているため、リクエストの優先度を区別する場合もある.例えば、リクエストが特に重要であれば、どうしてもストリームを制限する必要はない.では、別のlocationを構成し、ストリームを制限するlocationのurlのルールを書き、上限ストリームを割り当てるか、異なるlocationのストリーム制限ルールが異なると実現できます.
では、上記の制限フロー構成の効果は何なのかを分析します.rate=400 r/sが構成されているので、2.5 msごとにアプリケーション、つまりtomcatにリクエストを入れます.では、同時に、ここが同時にあることに注意してください.つまり、同じミリ秒に3000人が来ると、2.5 ms以内に1つのリクエストがtomcatに転送され、2000のリクエストがキュー内で転送されるのを待っていて、999のリクエストが直接503に戻ります.
キュー内の2000個のリクエストは400/sの速度で消費されます.つまり、5 s後にすべて処理されます.つまり、この構成に従って、キューが最後の人、つまり2000番目の人であれば、彼のリクエスト応答時間は5 s+tomcatがリクエストを処理する時間に等しいはずです.
これにより、私たちはストリーム制限の目的を達成し、私のシステムが常に最適な処理性能を保証することができます.
なぜ合併量が高いのか理解できない学生もいるかもしれませんが、TPS(毎秒リクエスト応答数)が下がるかもしれません.ここで説明します.例を挙げると、あなたのチームがプロジェクトをするとき、責任者として、責任を負う必要があるかもしれません.需要分析、機能設計、タスク分割、タスク割り当て、タスク検収などがあります.そして、具体的な仕事を実施してくれる人たちがいます.彼らがしていることは並行してやっていますが、同時に合併している人が特に多い場合は、一人の精力を消費することは限られています.あなたは数百人を同時に管理することはできません.誰かが分担しても限界に達し、無限に並行することはできません.そのため、限界に達した後、合併を続けると、処理能力が低下し、麻痺したり、ダウンタイムになったりする可能性があります.
これも、プロジェクトの工期が厳しい場合、私たちが狂って人を敷くことはないと言っている理由です.敷く人が多すぎるため、管理コストと各メンバー間のコミュニケーション調整コストが多くなり、かえって入金できない可能性があります.
ここではNginxをストリーム制限として採用するのは1つの方法で、WAF(ファイアウォール)、CDNなどのサービスを購入することで、ストリーム制限の能力を提供することもできます.
また、こちらも少しお話ししますが、limitモジュールにはもう一つの構成プロパティがあります.これは、自分のニーズシーンをフォローして使用するかどうかを評価することができます.

location / {
        limit_req zone=all_request_limit burst=2000 nodelay;
        proxy_pass http://api.xxxxx.cn;
        proxy_set_header   Host             $http_host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_502 http_504;
}

この構成のlimit_が表示されます.reqの構成の後ろにnodelayが1つ増えていますが、このパラメータはどういう意味ですか?
Nodelay:高同時シーンアプリケーションでは、キュー内のリクエストをすべてアプリケーションに転送しますが、キューを解放するわけではありません.つまり、キューがいっぱいで、新しいリクエストが来ると直接拒否され、(rate=400 r/s)つまり2.5 msの速度でキュー空間が徐々に解放され、後のリクエストが入ります.
このパラメータを追加するかどうかの効果は、「同時に」要求の山が来て、このパラメータを追加しなければ、これらの要求はすべてキューの中で2.5 msの速度で消費され、つまり2000人目の応答時間は必ず5 s+tomcatが要求を処理する時間であり、nodelayを追加すると2000人目の応答時間と最初の人の応答時間はtomcatの実際の応答時間である.なぜなら、彼らはtomcatに同時に転送され、待つことはなく、後のキューの解放時に2.5 msの速度で解放されるからだ.