Nginxセッション管理の解釈

セッションコンセプト

Session オブジェクトには、特定のユーザーセッションに必要なプロパティと構成情報が格納されます。このようにして、ユーザーがアプリケーションの Web ページ間を移動しても、Session オブジェクトに格納されている変数は失われることなく、ユーザーセッション全体にわたって保持されます。ユーザーがアプリケーションから Web ページを要求すると、ユーザーがまだセッションを持っていない場合、Web サーバーは自動的に Session オブジェクトを作成します。

問題の導入

クラスターモードでは複数のサーバーが存在し、クライアントが特定の時間にどのサーバーにアクセスするかはロードバランサーによって決定されるため、問題が発生します。ユーザーのセッション情報がサーバーに保存されている場合、ロードバランサーがセッション情報を転送するときに、ユーザーの次のリクエストは別のサーバーに送信されます。サーバー上にユーザーのセッション情報がないため、ユーザーは再度ログインする必要があります。そうしないと、特定のサーバー上で作成された重要なセッション情報が失われます。

純粋な IP ハッシュは LAN 内の IP にアクセスするようなもので、アクセスすると IP チルトが発生します。

Nginx_hash の高度な負荷分散

ip_ハッシュ

ip_hash を使用すると、ユーザーの IP が変更されていない限り、ユーザーアクセスがアップストリームサービスの固定サーバーを要求できるようになります。

ip_hash はアルゴリズムで、原理は非常に単純で、リクエストが属するクライアント IP に基づいて値を計算し、その値に対応するバックエンドにリクエストを送信します。つまり、同じクライアントからのリクエストは同じバックエンドに送信されるため、セッションを維持する効果が得られます。

異なる IP アドレスは、ip_hash の後に異なるハッシュ値を生成します。同じ IP は、ip_hash の後の値も同じになります。たとえば、サーバーが 2 台ある場合、値 %2 の残りを固定マシンにヒットできます。

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

バックエンドサーバーは直接削除できず、ダウンとしてマークすることのみ可能です。

この構成は中小企業には適していますが、大規模プロジェクトには適していません。1 つのバックエンドサーバーがダウンした場合、返信は中断され、再度ログインする必要があり、前の返信で保存されたデータはすべて失われ、ユーザーエクスペリエンスとセキュリティはあまり良くありません。

ハッシュ $cookie_xxx

$cookie_xxx: Cookie 内の変数を参照します。

upstream iphashserver {

        hash $cookie_grafana_session;
        server www.test.com:8002;
        server www.test.com:8003;

    }

cookie_grafana_session: 同じ grafana_session を運ぶリクエストは同じサーバーに分散されます。

同様に、php で sessionID を設定するか、Tomcat で jsessionid を設定して、会話を維持するという目的を達成することもできます。

ip_hash と cookie_jsessionid の違いは何ですか: ローカルエリアネットワークでは、全員が同じルーターに接続されています。サーバーを要求するとき、サーバーは同じ IP から呼び出しているとのみ認識し、それらはすべてルーター IP (ゲートウェイ) です。 ) なので、トラフィックが同じマシンに分散されると、バックエンドサーバーの負荷が不均衡になります。後者は sessionId によってよりハッシュ化されており、バックエンドサービスに均等に影響します。

cookie_jsessionid を使用してアップストリームでハッシュを構成してハッシュを実行する

#user  nobody;
worker_processes  1;
 
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
 
#pid        logs/nginx.pid;
 
 
events {
    worker_connections  1024;
}
 
 
http {
    include       mime.types;
    default_type  application/octet-stream;
 
 
    sendfile        on;
    #tcp_nopush     on;
 
    #keepalive_timeout  0;
    keepalive_timeout  65;
 
    #gzip  on;
   
    upstream backend {
        # 指定hash 方式是 cookie_jessionid nginx自带的方式
        hash $cookie_jsessionid;
        server 172.16.225.1:8081;
			  server 172.16.225.1:8080;
    }
 
    server {
        listen       80;
        server_name  localhost;
 
        #charset koi8-r;
 
        #access_log  logs/host.access.log  main;
 
        location / {
            # 指定负载到后端upstream
	    			proxy_pass http://backend;  
        }
 
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
 
}

ハッシュ $request_uri

原則: 同じ URI に対するリクエストは同じサーバーに送信されます。(uri: ドメイン名の後半を除いた完全な URL を指します)

 upstream iphashserver {

        hash $request_uri;
        server www.test.com:8001;
        server www.test.com:8002;

    }

補足知識: サーバーの拡張

1. ハードウェア拡張
概要: 垂直拡張とも呼ばれます。簡単に言うと、ハードウェアの追加や価格変更によってサーバーの高性能と交換することです。たとえば、メモリースティックを購入してSSDに交換します。

ボトルネック: 容量を拡張し続けるとボトルネックが発生します。たとえば、マザーボードは 100G のメモリしかサポートできません。どれだけ大きなメモリモジュールを接続しても関係ありません。マザーボードはそれをサポートしていないため、次のことを行う必要があります。横方向の拡張を追加します。

2. 水平方向の拡張
はじめに: クラスタリングを通じてサーバーのパフォーマンスを向上させます。