nginx ロードバランサーがセッション共有を処理するためのいくつかの方法

1) セッションを使用する代わりに、Cookie を使用します

セッションを Cookie に変更できれば、セッションの欠点のいくつかを回避できます。以前読んだ J2EE の本でも、セッションはクラスター内で使用できないと指摘していました。システムに問題が発生した場合、対応が困難になります。システムが複雑でない場合は、セッションを削除できるかどうかを優先し、変更が非常に面倒な場合は、次の方法を使用してください。

2) アプリケーションサーバーはそれ自体で共有を実装します

PHP はデータベースまたは memcached を使用してセッションを保存できることが知られており、これにより PHP 自体でセッションクラスターを確立できます。これにより、セッションの安定性が保証されます。ノードに障害が発生した場合でも、セッションは失われません。より厳しい状況ではあるがリクエスト量が少ない場合に適しています。ただし、効率はあまり高くないため、高い効率が要求される場面には適していません。

上記の 2 つの方法は nginx とは何の関係もありません。nginx の使用方法について話しましょう:

3) ip_hash

nginx の ip_hash テクノロジーは、特定の IP のリクエストを同じバックエンドに送信できるため、A が安定します。セッションは、この IP の下でクライアントとバックエンドに移動することで確立できます。 ip_hash はアップストリーム構成で定義されます:

upstream backend {
server 127.0.0.1:8001;
server 127.0.0.1: 8002;
ip_hash;
}

ip_hash は理解しやすいですが、バックエンドの割り当てに ip 要素のみを使用できるため、ip_hash には欠陥があり、場合によっては使用できません:

1/ nginx がフロントエンド サーバーではない。 ip_hash では、nginx がフロントエンド サーバーである必要があります。そうでない場合、nginx は正しい IP を取得できず、IP に基づいてハッシュできません。たとえば、Squid がフロントエンドとして使用されている場合、nginx は IP を取得するときに Squid のサーバー IP アドレスしか取得できません。このアドレスを配布に使用するのは間違いなく混乱します。

2/ nginx のバックエンドには、負荷分散の他の方法もあります。 nginx バックエンドに他の負荷分散があり、リクエストが別の方法で転送される場合、特定のクライアントからのリクエストは同じセッション アプリケーション サーバー上に存在しません。これを計算すると、nginx バックエンドはアプリケーション サーバーを直接指すか、Squid を構築してからアプリケーション サーバーを指すことしかできません。最善の方法は、位置情報を迂回として使用し、ip_hash を介したセッションを必要とする一部のリクエストを迂回し、残りは他のバックエンドに移動することです。

4)upstream_hash

ip_hash のいくつかの問題を解決するには、サードパーティ モジュールのupstream_hash を使用できます。ほとんどの場合、このモジュールは url_hash として使用されますが、セッション共有での使用が妨げられるわけではありません。
フロントエンドが Squid の場合、x_forwarded_for http_header に IP を追加します。このヘッダーを要素として使用して、指定されたバックエンドにリクエストを送ります:

このドキュメントを参照してください:

http://www .oschina.net/discuss /thread/622

ドキュメントでは、$request_uri が要素として使用されていますが、これを少し変更します:

hash $http_x_forwarded_for;

このように、x_forwarded_for ヘッダーを要素として使用するように変更されます。新しいバージョンの nginx では、cookie 値の読み取りをサポートできるため、次のように変更することもできます:

hash $cookie_jsessionid;

php で設定されたセッションが cookie なしの場合、nginx 独自の userid_module モジュールを使用すると、 nginxを使用してCookieを生成できます