Nginx----イベント処理メカニズムとプロセスモデル

Nginx イベント処理メカニズム:
基本的な Web サーバーの場合、通常、ネットワーク イベント、シグナル、タイマーの 3 種類のイベントがあります。
まず、リクエストの基本的なプロセスを見てみましょう: 接続の確立 --- データの受信 --- データの送信。
システムの下部の操作をもう一度見てください。上記のプロセス (接続の確立---データの受信---データの送信) は、システムの下部での読み取りおよび書き込みイベントです。

1) ブロッキングコール方式を使用した場合、読み取りおよび書き込みイベントの準備ができていない場合、読み取りおよび書き込みイベントは確実に実行できず、イベントが完了するまで長時間待たなければなりません。読み取りおよび書き込みイベントを実行する前に準備が完了しています。そうなるとリクエストも遅れてしまいます。呼び出しをブロックするとカーネルに入って待機し、CPU が他のユーザーによって使用されることになります。ネットワーク イベントが増えると、誰もが待機し、CPU を使用しなくなります。 CPU 使用率 当然のことながら、高い同時実行性はおろか、速度を上げることもできません。

2) 準備ができていない場合は通話をブロックすることはできないため、非ブロック方式を使用してください。非ブロックとは、イベントがすぐに EAGAIN に戻り、イベントの準備ができていないことを示します。なぜパニックになっているのでしょうか?しばらくしてから、イベントの準備ができるまでもう一度イベントを確認してください。この期間中は、他の作業を行ってから、イベントの準備ができているかどうかを確認してください。ブロックではなくなりましたが、イベントのステータスを時々確認する必要があります。できることは増えましたが、オーバーヘッドは小さくありません。読み取りおよび書き込み操作を実行すると、多くのオーバーヘッドが発生します。
3) したがって、非同期でノンブロッキングのイベント処理メカニズムが存在します。システム コールに固有なのは、select/poll/epoll/kqueue などのシステム コールです。これらは、複数のイベントを同時に監視できるメカニズムを提供します。呼び出しはブロックされますが、タイムアウト内にイベントの準備ができている場合は、タイムアウトを設定できます。このメカニズムにより、上記の 2 つの問題が解決されます。

epoll を例に挙げます。イベントの準備ができていない場合、イベントは epoll (キュー) に入れられます。準備ができているイベントがある場合は、イベントが EAGAIN を返した場合はそれを処理し、引き続き epoll に入れます。したがって、イベントの準備ができている限りそれを処理し、常に準備ができていない場合にのみ、epoll で待機します。このようにして、多数の同時リクエストを処理できます。もちろん、ここでの同時リクエストとは、スレッドが 1 つしかないため、同時に処理できるリクエストは 1 つだけです。リクエスト間を継続的に切り替えるだけです。非同期イベントの準備ができていないため、切り替えは自発的に中止されました。ここでの切り替えにはコストはかかりません。これは、複数の準備されたイベントをループで処理するものであると理解できます。これは実際に当てはまります。
4) マルチスレッドとの比較:
マルチスレッドと比較すると、このイベント処理方法には、スレッドを作成する必要がなく、各リクエストが占有するメモリが非常に少なく、コンテキストの切り替えがなく、イベント処理が非常に高速であるという大きな利点があります。軽量。同時実行がどれほど多くても、不必要なリソースの浪費 (コンテキストの切り替え) が発生することはありません。
概要: Nginx は、非同期のノンブロッキング イベント処理メカニズムを通じて、プロセスがループ内で複数の準備されたイベントを処理することを認識し、それによって高い同時実行性と軽量性を実現します。
Nginx の特徴:
1. クロスプラットフォーム: Nginx は、ほとんどの Unix などの OS 上でコンパイルして実行でき、Windows 用の移植バージョンもあります。
2. 設定は非常にシンプルで、簡単に始めることができます。構成スタイルはプログラム開発と同じ、神のような構成です
3. ノンブロッキング、高同時接続: データがコピーされるとき、ディスク I/O の最初の段階はノンブロッキングです。公式テストでは 50,000 の同時接続をサポートできますが、実際の運用環境では、同時接続数は 20,000 ～ 30,000 に達します (これは、Nginx が最新の epoll モデルを使用しているためです)
4. 通信メカニズムは、 epoll モデル、より多くの同時接続をサポートします。

5. nginx プロキシとバックエンド Web サーバーの間に長時間の接続は必要ありません。
6. ユーザー リクエストの受信は非同期です。つまり、すべてのユーザー リクエストが最初に受信され、その後バックエンド Web サーバーに送信されます。これにより、エンドエンド Web サーバーの負荷が大幅に軽減されます
7. 応答メッセージを送信するときに、バックエンド Web サーバーからデータを受信して​​クライアントに送信します
8.依存。 NGINX は、理論的には、ping が可能である限り、負荷分散を実装でき、イントラネットと外部のネットワーク トラフィックを効果的に区別できます
9。 NGINX は、ページの処理時にアプリケーション サーバーから返されたステータス コードとタイムアウト情報に基づいてサーバーが失敗したかどうかを検出し、他のノードに再送信するための誤ったリクエストを即座に返すことができます:

マスター/ワーカー構造: A。マスタープロセスは 1 つまたは複数のワーカープロセスを生成します
低メモリ消費: 大量の同時リクエストの処理で消費されるメモリはほとんどありません。 30,000 の同時接続の下では、開始された 10 個の Nginx プロセスは 150M のメモリしか消費しません (15M*10=150M) 低コスト: Nginx はオープンソース ソフトウェアであり、無料で使用できます。 F5 BIG-IPやNetScalerなどのハードウェア負荷分散スイッチの購入には10万元以上から数十万元の費用がかかります。 組み込みのヘルスチェック機能：Nginx ProxyのバックエンドのWebサーバーがダウンすると、フロントエンドのアクセスが停止します。影響を受けないこと。
帯域幅の節約: GZIP 圧縮をサポートし、ブラウザによってローカルにキャッシュされたヘッダーを追加できます。
高い安定性: リバースプロキシに使用され、ダウンタイムの可能性は非常に小さいです
nginx はマルチプロセス方式で動作します。もちろん、nginx はマルチスレッド方式もサポートしていますが、依然としてデフォルトのマルチプロセス方式が主流です。 nginxのモード。マルチプロセスアプローチを使用する nginx には多くの利点があります。
(1) nginx が開始されると、マスタープロセスと複数のワーカープロセスが存在します。マスター プロセスは主にワーカー プロセスの管理に使用されます。これには、外部からのシグナルの受信、各ワーカー プロセスへのシグナルの送信、ワーカー プロセスの実行ステータスの監視、ワーカー プロセスの終了時に新しいワーカー プロセスを自動的に再起動するなどが含まれます。異常事態）。基本的なネットワーク イベントはワーカー プロセスで処理されます。複数のワーカー プロセスはピアツーピアであり、クライアントからのリクエストを平等に競合し、各プロセスは互いに独立しています。リクエストは 1 つのワーカー プロセスでのみ処理でき、ワーカー プロセスは他のプロセスからのリクエストを処理できません。 ワーカー プロセスの数は、通常、マシンの CPU コアの数と一致するように設定します。これは、nginx のプロセス モデルとイベント処理モデルと切り離すことができません。
(2) シグナルを受信した後、マスターはどのようにシグナルを処理しますか (./nginx -s reload)
まず、シグナルを受信した後、マスタープロセスは設定ファイルをリロードし、新しいプロセスを開始し、古いプロセスをすべて送信します。プロセスは、名誉ある退職をすることができるという信号を送信します。新しいプロセスが開始されると、新しいリクエストの受信を開始しますが、古いプロセスはマスターからシグナルを受信した後、現在のプロセス内の未処理のリクエストがすべて処理された後、新しいリクエストの受信を停止し、終了します。
(3. ) ワーカー プロセスはリクエストをどのように処理しますか?
ワーカー プロセスは平等であり、各プロセスにはリクエストを処理する同じ機会があると前述しました。ポート 80 で http サービスを提供し、接続要求が来た場合、各プロセスが接続を処理します。まず、各ワーカープロセスがマスタープロセスからフォークします。マスタープロセスでは、まずリッスンする必要のあるソケットが確立され、次に複数のワーカープロセスがフォークされ、各ワーカープロセスがソケットを受け入れることができます（もちろんそうではありません）。同じソケットですが、各プロセスのソケットは同じ IP アドレスとポートで監視されます。これはネットワーク プロトコルで許可されています。一般に、接続が到着すると、ソケットを受け入れるすべてのプロセスが通知を受け取りますが、1 つのプロセスだけが接続を受け入れ、他のプロセスは受け入れられません。これは、いわゆるサンダーリング現象です。もちろん、nginx は見て見ぬふりをしません。そのため、nginx は accept_mutex を提供します。名前から、これが受け入れのために追加された共有ロックであることがわかります。このロックを使用すると、同時に accpet に接続するプロセスは 1 つだけになるため、激しい群れの問題は発生しません。 accept_mutex は、明示的にオフにできる制御可能なオプションです。デフォルトではオンになっています。ワーカー プロセスが接続を受け入れると、リクエストの読み取り、解析、処理が開始され、データが生成されてからクライアントに返され、最後に接続が切断されます。これが完全なリクエストです。リクエストはワーカー プロセスによって完全に処理され、1 つのワーカー プロセスでのみ処理されることがわかります。
(4) nginx がこのプロセスモデルを採用するメリットは何ですか?
独立したプロセスを使用しても、相互に影響を与えることはありません。1 つのプロセスが終了しても、他のプロセスは引き続き動作し、マスター プロセスはすぐに新しいワーカー プロセスを再開します。もちろん、ワーカー プロセスが異常終了した場合、プログラムにバグがあるはずです。異常終了により、現在のワーカー上のすべてのリクエストが失敗しますが、すべてのリクエストには影響しないため、リスクは軽減されます。もちろんメリットもたくさんあり、誰でもゆっくりと体験することができます。
(5) nginx はリクエストを処理するためにマルチワーカー方式を使用します。そのため、処理できる同時実行数は非常に限られています。どのようにして多数のワーカーを処理できるのでしょうか。高い同時実行性?いいえ、これが nginx の優れた点です。nginx は非同期で非ブロッキングなメソッドを使用してリクエストを処理します。つまり、nginx は同時に数千のリクエストを処理できます。

IIS サーバーの場合、各リクエストは排他的になります。ワーカー スレッドの場合、同時実行数が数千に達すると、数千のスレッドが同時にリクエストを処理することになります。これはオペレーティング システムにとって大きな課題であり、スレッドによるメモリ使用量は非常に大きく、当然のことながら、パフォーマンスは向上せず、これらのオーバーヘッドはまったく意味がありません。ワーカーの数を CPU コアの数に設定することが推奨されると以前に述べましたが、これは簡単に理解できますが、ワーカーの数が増えると、プロセスが CPU リソースを求めて競合し、不必要なコンテキストの切り替えが発生します。さらに、マルチコア機能をより有効に活用するために、nginx は、プロセスの切り替えによってキャッシュが失敗しないように、特定のプロセスを特定のコアにバインドできる CPU アフィニティ バインド オプションを提供します。

負荷分散

負荷分散テクノロジーは、既存のネットワーク構造に加えて、ネットワークデバイスとサーバーの帯域幅を拡張し、スループットを向上させ、ネットワークデータ処理機能を強化し、ネットワークの柔軟性を向上させる、安価で効果的かつ透過的な方法を提供します。そして可用性。これには 2 つの意味があります。1 つは、大量の同時アクセスまたはデータ トラフィックが個別の処理のために複数のノード デバイスに共有され、ユーザーが応答を待つ時間が短縮されることです。2 つ目は、単一の高負荷操作が並列のために複数のノード デバイスに共有されることです。各ノードデバイスが処理された後、結果が要約されてユーザーに返され、システムの処理能力が大幅に向上します

以上、Nginxのイベント処理機構とプロセスモデルについて、その側面も含めて紹介しましたが、PHPチュートリアルに興味のある方の参考になれば幸いです。