nginx関連のナレッジポイントのまとめと共有-PHPチュートリアル-php.cn

Nginx 自体は PHP を解析しません。PHP ページに対するターミナルのリクエストは、Nginx によって FastCGI プロセスによって監視される IP アドレスとポートに渡され、動的解析サーバーとして php-fpm によって処理されます。処理結果はnginxに返されます。実際、Nginx はリバースプロキシサーバーです。 Nginx は、リバースプロキシ機能を通じて動的リクエストをバックエンド php-fpm に転送することで、PHP 解析のサポートを実現します。これが、Nginx が PHP 動的解析を実装する原理です。

Nginx は、外部プログラムの直接呼び出しや解析をサポートしていません。すべての外部プログラム (PHP を含む) は、FastCGI インターフェイスを通じて呼び出す必要があります。 FastCGI インターフェイスは、Linux 上のソケットです (このソケットはファイルソケットまたは IP ソケットにすることができます)。 CGI プログラムを呼び出すには、FastCGI ラッパーも必要です (ラッパーは、別のプログラムを開始するために使用されるプログラムとして理解できます)。このラッパーは、ポートやファイルソケットなどの固定ソケットにバインドされます。 Nginx が CGI リクエストをこのソケットに送信すると、ラッパーは FastCGI インターフェイスを通じてリクエストを受信し、新しいスレッドを生成してスクリプトを処理し、返されたデータを読み取ります。返されたデータは、FastCGI インターフェイスを介して固定ソケット経由で Nginx に渡され、最後に、Nginx は返されたデータをクライアントに送信します。

古典的なモデルは、Nginx で使用されるマスター-ワーカーマルチプロセス非同期ドライバーモデルです。

親プロセスがソケットを作成し、バインドしてリッスンすると、フォークを通じて複数の子プロセスが作成され、各子プロセスは親プロセスのソケットを継承し、accpet を呼び出してネットワーク接続のリッスンと待機を開始します。このとき、同時に複数のプロセスがネットワーク接続イベントを待っていますが、このイベントが発生すると、これらのプロセスが同時に目覚めることになり、これは「ショック」です。プロセスが起動されると、各プロセスがこのイベントに同時に応答するようにカーネルを再スケジュールする必要があり、最終的に 1 つのプロセスだけがイベントを正常に処理でき、他のプロセスは再スリープするか、イベントの処理に失敗します。イベント。

実際、Linux バージョン 2.6 以降、カーネルは accept() 関数の「ショック」問題を解決しました。カーネルは顧客接続を受信すると、待機キュー内の最初のプロセスまたはスレッドのみを起動します。

この問題を解決するには、Nginx で accept_mutexmutex ミューテックスロックが使用されます。具体的な対策には、アプリケーションが取得できない場合は、グローバルミューテックスロックを適用することが含まれます。取得されると、待機して負荷分散アルゴリズム (特定のサブプロセスのタスク量が設定された合計量の 7/8 に達すると、ロックの適用はそれ以上試行されなくなります) を設定して、タスク量のバランスをとります。それぞれのプロセス。

ここで、サンダーリンググループと Nginx の処理を次のように要約します:

accept はサンダーリンググループを引き起こしませんが、epoll_wait はサンダーリンググループを引き起こします。
Nginx の accept_mutex は、accept パニックの問題を解決しませんが、epoll_wait パニックの問題を解決します。
Nginx が epoll_wait パニック問題を解決するのは、リッスンするソケットを epoll に追加するかどうかだけを制御する、というのも間違いです。待機ソケットは 1 つの子プロセスの epoll 内にのみ存在します。新しい接続が到着しても、他の子プロセスは確実に起動しません。

簡単に言うと、同時に 1 つの nginx ワーカーだけが、自身の epoll でリスニングハンドルを処理できます。負荷分散も非常に簡単で、最大接続の 7/8 に達すると、ワーカーは受け入れロックを取得しようとせず、新しい接続を処理しないため、他の nginx ワーカープロセスが接続を処理する機会が増えます。新しい接続が確立されます。また、タイムアウトの設定により、ロックを取得していないワーカープロセスがロックを取得する頻度が高くなります。

nginx マルチプロセスモデルは本当にロックフリーですか?実際には、ngx_accept_mutex がまだ存在します。

nginx はマルチプロセスプログラムであり、ポート 80 が各ワーカープロセスによって共有されるため、接続が来るたびに複数のワーカープロセスが競合して応答することになります。これがいわゆるサンダーリングハード現象です。

カーネルがリンクを受け入れると、待機中のすべてのプロセスがウェイクアップされますが、実際には 1 つのプロセスのみが接続を取得でき、他のプロセスは無効にウェイクアップされ、アプリケーションのオーバーヘッドが確実に増加します。この目的を達成するために、nginx は受け入れロックを提供し、9 人の息子が相続人を引き継ぐという悲劇を回避します。

ngx_accept_mutex の機能は、現在負荷の高いワーカープロセス

が新しい受信リクエストの処理を積極的に放棄できるようにし、

アプリケーションの全体的なウェイクアップ効率を向上させ、それによってアプリケーションの全体的なパフォーマンスを向上させることです。。

proxy_cache

upstream

fastcgi_pass

location

非標準ステータスコード 444 は、接続が閉じられ、クライアントに応答ヘッダーが送信されないことを意味します。

nginx -s reload コマンドは、変更された設定ファイルをロードします。

1. Nginx のマスタープロセスが設定ファイルの正しさをチェックし、間違っている場合はエラーメッセージが返され、nginx は続行します。元の設定ファイルを使用して動作するため (ワーカーには影響しないため)

2. Nginx は新しいワーカープロセスを開始し、新しい設定ファイルを採用します

3. Nginx は新しいリクエストを新しいワーカープロセスに割り当てます

4.前のワーカープロセスからのすべてのリクエストが完了するまで待機します。すべて戻ったら、関連するワーカープロセスを閉じます

5. 古いワーカープロセスがすべて閉じるまで、上記のプロセスを繰り返します

上記のプロセスは、nginx の関連する公式ドキュメントに基づいています。

proxy_next_upstream を例に挙げると、一般的な設定は次のとおりです:

proxy_next_upstream http_504 タイムアウト;

このコマンドには 2 つの機能があります:

接続タイムアウトが発生し、アップストリームが 504 を返す必要があることを nginx に伝えます。
nginx、http 504、接続タイムアウトはリクエストの失敗であると伝えます

一般に、nginx はデフォルトで error、timeout、invalid_header で失敗します。他の動作を失敗として扱いたい場合は、次のようにする必要があります。クラスディレクティブにproxy_next_upstreamのようなものを追加します。このうち http_403 と http_404 が認識されない場合は失敗です。

サーバー障害の定義と障害後のサーバーの動作の 2 つの点について説明します。

サーバー障害の定義: 上記のモジュール障害定義は主に、どのような状況でリクエストが失敗するかを説明するために使用されますが、サーバーが障害として定義されるのは何でしょうか? nginx は主に、max_fails とfail_timeout という 2 つのパラメータを使用して制御します。簡単に言うと、リクエストがfail_timeout以内にmax_fails回失敗した場合、サーバーが現在ダウンしていることを意味します。