nginxのアプリケーションシナリオ

nginxの三つの主要なシナリオ：

静的リソースサービス
リバースプロキシサービス
APIサービス

静的リソースサービス

nginxのは、このような純粋な静的なHTMLページとして、ローカルファイルシステムで静的リソースを果たすなどができます。

リバースプロキシサービス

多くのサービスアプリケーションの効率が非常に低い、QPS、TPS、同時実行が制限され、ユーザにサービスの高可用性を提供するために、クラスタを構成するアプリケーションやサービスの多くを置くことが必要である、nginxのにこの時間必要がプロキシ機能を逆転されて動作させます、およびアプリケーション・サービスの動的拡張は、ロード・バランシング、別の、nginxのバッファ層のニーズが行われるために必要とします。したがって、リバースプロキシサービスは、次の3つの機能は、主に以下のとおりです。

リバースプロキシ
ロードバランシング
キャッシュ

APIサービス

時には、アプリケーションサービス自体は、パフォーマンスの問題の多くを持っていますが、より良いサービスのデータベース・アプリケーション・サービス、ビジネスシナリオは比較的単純で、同時実行性とTPSよりもアプリの場合よりもはるかに高いことが、ので、この時間は、Redisのnginxのへたりから直接データベースにアクセスすることができますまた、nginxのの強力な並行処理でAPIサービスアプリケーションファイアウォールを実現することができます。

nginxの建築財団

nginxのステートマシン

Web、電子メール、TCPトラフィック：nginxの外部サービスは、3つのトラフィックは、nginxのに達するがある場合。3つのフローはnginxのに到達した後、それぞれ、トランスポート層ステートマシン、アプリケーション層の状態マシン、MAIL状態機械によって処理されるであろう。メモリはすべての静的リソースをキャッシュするのに十分でない場合は、通話をブロックするために、ディスクを退化されます、あなたは、この時点でハンドルにスレッドプールを必要とする、記録アクセスログとエラーログを処理し、各要求のために、ログがディスクに記録されています。

nginxのプロセス構造

nginxの4つのプロセスがあります。

マスタープロセス。マスタープロセスは、ワーカープロセスのマスタープロセスを管理するために、他のプロセスが子プロセスは、親プロセスであります
ワーカープロセス。複数のワーカープロセスがありますが、それは特定の要求を処理する責任があります。nginxのはなぜマルチプロセス、マルチスレッドプロセスではなく、構造？nginxのは、高可用性を確保するので、特定のサードパーティのモジュールは、セグメンテーションフォールトにつながったときに、それがハングnginxのに全体のプロセスが発生します、複数のスレッド間のアドレス空間を共有します。マルチプロセス・モデルは、この問題を持っていません
キャッシュマネージャとキャッシュローダープロセス。キャッシュに加えて、だけでなく、キャッシュのプロセスを使用して、複数のワーカー・プロセスによって使用される、キャッシュのロード、キャッシュ管理マネージャとしてキャッシュローダはキャッシュない、キャッシュは、実際に要求ごとに、またはワーカープロセスに使用されます。これらのプロセス間の通信は、共有メモリを介して行われます

なぜワーカープロセスは、多くのことを必要としますか？

あなたがより効率的に、CPUのキャッシュヒット率を向上させ、ワーカープロセスをCPUの全作品を使用することができますので、これはまた、可能nginxのは、イベント駆動型モデルを使用し、それは最初から最後までワーカープロセスを期待するからであるCPUを埋めることができます1つのCPUコアと一緒に結合。

親と子の信号管理nginxのの使用

コマンドラインの前にnginxのといえば、実際には、多くのnginxの信号を達成するために介してマスタプロセスにシグナルを送っています。

マスター・プロセス

マスター・プロセスは、ワーカープロセスを監視し、子プロセスがLinuxの出口で指定されたときに親プロセスCHLDに信号を送信する必要の実現を監視します。すぐに労働者を引っ張ったときに、このバグが発生します。

マスター・プロセスは、次の信号を受け取ることができます。

TERM、INT
終了する
HUP
USR1
USR2
ウインチ

ワーカープロセス

ワーカープロセスは、次の信号を受信することができます。

TERM、INT
終了する
HUP
USR1
ウインチ

コマンドラインに対応する信号

リロード：HUP
再度開く：USR1を
停止：TERM
終了：QUIT

WINCH USR2および該当する信号のみキルを介して送信されます。

ストップの違いと終了は、1がすぐに出ている、ある優雅な駅です。

真実リロードリロード設定ファイル

マスター・プロセスにHUPシグナルを送ります
マスター設定ファイルの構文の問題かどうかをチェックする処理
（新しいポート設定ならば）新しいマスター・プロセス・モニタポートを開きます
マスター・プロセスは、新しいコンフィギュレーション・ファイルのワーカープロセスを使用して開始します
古いワーカープロセスにシグナルを送り、マスター・プロセスを終了します
現在の接続が終了した後、プロセスを終了し、古いワーカープロセスシャットダウン監視ハンドル、

ホットデプロイの真実

ホットデプロイの流れについて前回の記事では、特定のプロセス熱の展開はどのようにそれのようなものでしょうか？

（バックアップそのノート）古い新しいnginxのnginxのファイルにファイルを置き換えます
USR2は、マスター・プロセスにシグナルを送ります
接尾.oldbinマスタープロセスpidファイル名を変更
新しいマスター・ファイルを使用して新しいプロセスを開始するためのマスタープロセスnginxの
送信は、古いマスター・プロセスにシグナルを終了し、古いマスターをシャットダウン
ロールバック、古いマスター・プロセスにHUPシグナルを送って、新しいマスター送信がQUIT

ワーカープロセスオフエレガントなターン

タイマーworker_shutdown_timeoutを設定します
閉じるリスナーハンドル
閉じるアイドル接続
すべての接続を待って再循環を閉じました
プロセスを終了します

そこでは、タイマーの役割、タイムアウトであれば、しかし、接続はまだプロセスから撤退を余儀なくされ、処理されていません。また、nginxのは、唯一のエレガント閉じ、WebSocketを、TCP、UDPプロキシが行うことができない、作業員がデータを解析しないHTTPを扱うことができます。

これらの内容は、プロセスが完了しnginxのコマンドラインと信号があります。次回はHTTPモジュールを話し始めました。

いいえ世間の注目を受けるnginxの知識マップ