nginxコアアーキテクチャの概要

卒業前、プロジェクトの完了後、しばらくソケット プログラミングに取り組み、C++ の Qt フレームワークを使用して、おもちゃのような TCP および UDP 通信クライアントを作成しました。直属の先輩と電話で話していたとき、ソケットをさらに深く掘り下げて、バックエンドまたはアーキテクトのルートを選択するようにアドバイスされました。ソケット関連の知識を学びたい場合は、サーバーのソースコードを学ぶのが最適です。どのサーバーを選択するかについては、慎重に検討し調査した結果、重くて容量の大きい Apache に比べて、nginx が小さくて優れていることがわかりました。そのため、ソース コードを正式に使用し始める前に、まず自己普及活動を開始しました。

1、プロセスモデル

まず、デフォルトでは、他のサーバーと同様に、Unix下のnginxもdaemon（デーモン）の形でバックグラウンドで実行され続けます。プロセス）。 nginxは、デバッグ目的でバックグラウンドモードをオフにしてフォアグラウンドモードを使用することもできますが、構成(後で詳しく説明します)を通じてマスタープロセスをキャンセルすることもできます。 は単一プロセスのWorkとして使用できます。しかし、これらは nginx が誇るアーキテクチャとはほとんど関係がないため、ここではリストしません。 nginx もマルチスレッドをサポートしていますが、それでもデフォルトのマルチプロセス モードを理解することに重点を置きます。 nginxは起動後、

masterプロセス（メインプロセス）といくつかのworkerプロセス（スレーブプロセス）を作成します。 masterプロセスは主にworkerプロセスの管理を担当し、特に管理者からシグナルを受信し、対応するworkerプロセスに転送します。プロセスが異常終了した場合、 worker プロセスを再作成して起動します。 worker プロセスは、基本的なネットワーク イベントの処理を担当します。 ワーカー プロセスは同じ優先順位を持ち、クライアントからのリクエストに対して公平に競合します。各リクエストは 1 つの ワーカー プロセスによってのみ処理されます。 nginxプロセスモデルの概略図を図1に示します。 N g g1 Nginx プロセス モデル 有意図 Worker プロセスの数を設定できます。一般に、設定はイベント処理モデルに関連する CPU の数と一致します。

nginx

のイベント処理モデルについては、後ほど引き続き紹介していきます。

2. シグナルとリクエスト nginx は、管理者からのシグナルとクライアントからのリクエストという 2 つのインターフェイスを通じて外部と対話します。以下に、

nginxがシグナルとリクエストを処理する方法を示す例を示します。 nginxを制御するには、管理者はmasterプロセスと通信する必要があり、コマンド信号をmaster

プロセスに送信するだけです。たとえば、

nginxは、kill -HUP [pid]コマンドを使用して、バージョン

0.8より前のnginxを再起動しました。このコマンドを使用して nginx を再起動すると、サービスを中断することなくグレースフル リスタート プロセスが実現します。 HUPコマンドを受信した後、masterプロセスはまず設定ファイルをリロードし、次に新しいworkerプロセスを開始し、古いworkerプロセスに停止信号を送信します。この時点で、新しい worker プロセスはネットワーク リクエストの受信を開始し、古い worker プロセスは現在のリクエストが処理された後、終了して終了します。破壊されました。バージョン 0.8 以降、nginx では、サーバー管理を容易にするための一連のコマンドライン パラメーター (それぞれ ./nginx -s reload や ./nginx -s stop) が導入されました。 nginxの再起動と停止に使用されます。操作コマンドを実行すると、実際には新しい nginx プロセスが開始されます。コマンド内のパラメーターを解析した後、このプロセスは対応するシグナルを独自に master プロセスに送信し、送信と同じ目的を達成します。エフェクトの前に手動で信号を入力します。 3. リクエストとイベント

サーバーは、80ポートhttpプロトコルからのリクエストを処理することがほとんどです。nginxのリクエスト処理プロセスを説明するための例として考えてみましょう。まず、各 worker プロセスは、master プロセス fork (フォークされた) から形成されます。 (ソケット、つまり IPアドレス+ポート番号) と、対応するlistenfd (リスニングファイル記述子またはハンドル) が最初に確立されます。 socket通信の各プロセスにはポート番号を割り当てる必要があり、workerプロセスのsocket割り当て作業はmasterプロセスによって完了することがわかっています。新しい接続が到着すると、すべての worker プロセスの listenfd が読み取り可能になり、1 つの worker プロセスだけが接続を処理するように、各 worker プロセスが listenfd に登録されます。 イベントを読み取る前に、まず accept_mutex (接続ミューテックスを受け入れる) を取得する必要があります。worker プロセスが接続を正常に取得した後、リクエストの読み取り、リクエストの解析、処理が開始されます。そしてそのデータをクライアントにフィードバックします。 4. プロセス モデル分析 nginx は、マルチプロセス リクエスト処理モデル (PPC) を使用しますが、使用するだけではありません。各

ワーカー

プロセスは、一度に 1 つのリクエストのみを処理し、リソースを作成します。リクエスト間では独立したロックが必要であり、リクエストは相互に影響を与えることなく並行して処理できます。リクエスト処理の失敗により、workerプロセスが異常終了しますが、サービスは中断されません。代わりに、masterプロセスが直ちに新しいworkerプロセスを再起動し、直面する全体的なリスクを軽減します。サーバーが安定し、サービスがより安定します。ただし、マルチスレッドモデル (TPC) と比較すると、システムのオーバーヘッドがわずかに大きく、効率が若干低いため、他の手段で改善する必要があります。 5. nginx の高い同時実行メカニズム——非同期ノンブロッキングイベントメカニズム

IIS

のイベント処理メカニズムはマルチスレッドであり、各リクエストには排他的な作業スレッドがあります。マルチスレッドはより多くのメモリを消費するため、スレッド間のコンテキスト切り替え (レジスタ グループの保護と復元の繰り返し操作) によって引き起こされる CPU のオーバーヘッドも非常に大きくなり、マルチスレッド メカニズムを備えたサーバーは数千もの同時実行に直面します。データ量が増加すると、システムに多大な負荷がかかり、高い同時実行パフォーマンスは理想的ではありません。もちろん、ハードウェアが十分に優れており、十分なシステム リソースを提供できる場合は、システムの負荷は問題になりません。 。

マルチプロセスとマルチスレッド、ブロッキングメカニズムとノンブロッキングメカニズムの違いについて、システムレベルまで詳しく見ていきましょう。

オペレーティング システムに精通している学生は、マルチスレッドの出現により、リソースが十分なときに CPU をより完全にスケジュールして使用できるようになり、マルチコア CPU の使用率を向上させることが特に有益であることを理解する必要があります。

。ただし、スレッドはシステム タスクの最小単位であり、プロセスはシステム リソース割り当ての最小単位です。これは、マルチスレッドが大きな問題に直面することを意味します。スレッドの数が増加し、リソース要件が増加すると、これらの親プロセスが増加します。スレッドは、すべてのスレッドに十分なリソースを一度にすぐに適用することは不可能です。システムにプロセスを満たすのに十分なリソースがない場合、プロセス全体を待機させることを選択します。このとき、一部のスレッドが正常に動作するのに十分なシステム リソースがあったとしても、親プロセスはこれらのリソースを適用できないため、すべてのスレッドが一緒に待機することになります。率直に言うと、マルチスレッドを使用すると、プロセス内のスレッドを柔軟にスケジュールできます (ただし、スレッドのデッドロックのリスクとスレッド切り替えのコストが増加します)。ただし、親プロセスがシステム内で引き続き動作できるという保証はありません。より大きく重くなった場合は、適切なスケジュールを設定してください。マルチスレッドによって確かに

CPU の使用率が向上することはわかりますが、サーバーの CPU の使用率が高いことは言うまでもなく、同時に発生するサーバーリクエストが多いという問題を解決するのに理想的なソリューションではありません。高い同時実行状態を維持します。上記はIISのマルチスレッド同期ブロッキングイベントメカニズムです。 nginx のマルチプロセス メカニズムにより、条件が満たされると、各リクエストがシステム リソースに個別に適用され、各リクエストはすぐに処理されます。つまり、非同期のノンブロッキング処理です。ただし、プロセスの作成に必要なリソースのオーバーヘッドはスレッドのオーバーヘッドよりも大きくなります。プロセスの数を節約するために、nginxは、I/O

イベント処理だけでなく、いくつかのプロセススケジューリングアルゴリズムを使用します。マルチプロセスメカニズムに依存しますが、非同期のノンブロッキングマルチプロセスメカニズムです。次に、nginxの非同期ノンブロッキングイベント処理の仕組みを詳しく紹介します。 6、エポール

Linux では、高い同時実行性を備えた高性能ネットワークは、epoll、nginx もネットワーク イベントの処理メカニズムとして epoll モデルを使用する必要があります。まず、epollがどのように生まれたのかを見てみましょう。

最も初期のスケジューリング ソリューションは、非同期ビジー ポーリング方法、つまり、socket コレクションのアクセス ステータスをトラバースする、I/O イベントの継続的なポーリング方法です。サーバーがアイドル状態のときのトラフィックCPUのオーバーヘッド。 E その後、スケジューリング プロセスのエージェントとして leSelect

と

Poll が登場し、改良された CPU ユーティリティが文字通り「 」 として登場しました。 です」 Poll"、それらは本質的に同じであり、両方のポーリングsocketがリクエストを収集して処理します。前との違いは、I/Oイベントを監視できることです。ポーリングスレッドはアイドル時にブロックされ、1 つ以上の I/O イベントが到着すると起動され、「ポーリング中」「の 」 忙しい" 、非同期ポーリング方式になります。 select/poll モデルは、FD (ファイル記述子) コレクション全体、つまり socket コレクションをポーリングします。ネットワーク イベントの処理効率は、同時リクエストの数に応じて直線的に低下します。マクロを使用して最大同時接続数を制限します。同時に、select/pollモデルのカーネル空間とユーザー空間間の通信方法はメモリコピーであり、高いオーバーヘッドをもたらします。上記の欠点により、新しいモデルが作成されました。 epoll

は

event vote の略語と考えることができます。 は、ファイル記述子の大規模なバッチを処理するために改良された Linux カーネルです poll、それは Linux ロングベット 道路多重化 I/O インターフェース select/poll の強化版。これにより、プログラムのアクティブな接続数が少ない場合に、システム CPU の使用率を大幅に向上させることができます。多数の同時接続。 まず第一に、epollには同時接続の最大数に制限はありません。上限は1GBのハードウェアメモリサイズに関連しています。マシン、それは約 10w; そして、epollの最も重要な利点は、「active」でのみ動作することです。カーネルI/O読み取りおよび書き込みイベントによって非同期に起動されます。socketはreadyキューに入れられ、workerプロセスによって処理される準備ができています。実際の運用環境ではポーリングのオーバーヘッドが大きくなり、イベント処理の効率が大幅に向上します。 最後に、epollは、カーネル空間とユーザー空間の間の通信を実現するために共有メモリ(MMAP)を使用し、メモリコピー。また、nginxで使用されるepollのET(エッジトリガー)動作モードは高速動作モードです。 heatモードは非ブロッキングソケットのみをサポートしています。のステータスの場合にも通知は送信されますが、FDの準備ができていない原因となるI/O操作がなかった場合、通知は送信されなくなります。一般に、Linuxのnginxはイベントベースであり、epollを使用してネットワークイベントを処理します。 著作権声明: この記事はブロガーによるオリジナルの記事であり、ブロガーの許可なく複製することはできません。 上記では、nginx のコア アーキテクチャの概要をその側面も含めて紹介しましたが、PHP チュートリアルに興味のある友人に役立つことを願っています。