1) セッションを使用する代わりに、Cookie を使用します
セッションを Cookie に変更できれば、セッションの欠点のいくつかを回避できます。以前読んだ J2EE の本にも、セッションがクラスタ システムでは使用できないと記載されていました。 , そうしないとトラブルが起きた時の対処が難しくなります。システムが複雑でない場合は、セッションを削除できるかどうかを優先してください。変更が非常に面倒な場合は、次の方法を使用してください。
2) アプリケーションサーバーは自ら共有を実現します
PHPはデータベースやmemcachedを利用してセッションを保存できることが知られており、これによりPHP自体でセッションクラスターを確立することができます。特定のノードに障害が発生した場合でも、セッションが失われることはありません。より厳しい状況ではあるが、リクエスト量が少ない場合に適しています。ただし、効率はあまり高くないため、高い効率が要求される場面には適していません。
上記の 2 つの方法は nginx とは何の関係もありません。nginx の使用方法について話しましょう:
3) ip_hash
nginx の ip_hash テクノロジーは、特定の IP のリクエストを同じコンピューターに送信できます。この IP の下でクライアントとバックエンドが安定したセッションを確立できるように、ip_hash はアップストリーム構成で定義されます:
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 のいくつかの問題を解決するために、このモジュールはほとんどの場合 url_hash として使用されますが、セッションでの使用を妨げるものではありません。共有:
フロントエンドがsquidの場合、upstream_hashを使用して、このヘッダーを要素として使用して、指定されたバックエンドにリクエストを送信できます:
このドキュメントを参照してください。 :
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 を生成できます。userid モジュールの英語ドキュメントを参照してください:
http://wiki.nginx.org/NginxHttpUserIdModule
上記では、内容の側面も含め、nginx ロード バランサーがセッション共有を処理するためのいくつかの方法を紹介しました。PHP チュートリアルに興味のある友人に役立つことを願っています。