nginx がセッションを共有する方法

nginx が負荷分散を行う場合、同じ IP の URL がサーバーをリクエストすると、負荷分散は各サーバーの重みやその他の設定に基づいて処理するためにリクエストを別のサーバーに転送します。ステータスリクエストの場合、これは大きな問題です。セッションを共有できないので、どうすれば解決できますか?

セッションは、データベース mysql

セッションはデータベースに保存され、セッション テーブルと他のデータ テーブルが一緒に保存されます。その後、ユーザーがログインして操作を実行するときに、データベースにアクセスして確認する必要があります。これは間違いなく、セッションのステータスです。これにより、MySQL データベースへの負荷が増大します。データベースもクラスタ化されている場合、データベース クラスタの各ノードは、セッション テーブルと、データベースのセッション テーブルのデータをそれぞれのノードに保存する必要があります。リアルタイム同期

説明: セッションがデータベースに残るため、データベースの IO が増加し、データベースへの圧力と負荷が増大し、その結果、クラスタ ノードに影響が及びます。データベースの読み取りおよび書き込みパフォーマンスが低下し、mysql クラスターに貢献しません。セッションのリアルタイム同期

session はキャッシュ memcache または redis

memcache に存在します。配布可能で、php設定ファイルで保存方法がmemcacheに設定されているのでphpが勝手に作成してくれる セッションクラスタはセッションデータをmemcacheに保存します。

注: この方法でセッションを同期すると、データベースへの負担が増加せず、Cookie を使用してセッションを保存する場合に比べてセキュリティが大幅に向上します。ファイルからの読み取りは、セッションを保存するよりもはるかに高速です。ただし、me​​mcache はメモリをさまざまな仕様のストレージ ブロックに分割し、各ブロックには独自のサイズがあります。この方法では、memcache がメモリを完全に利用できず、メモリの断片化が発生します。十分なストレージ ブロックがない場合、メモリ オーバーフローが発生します。 。

ip_hash テクノロジー

nginx で設定できます。特定の IP 下のクライアントが指定されたリクエストを行うとき (ハッシュ値は IP アドレスに基づいて計算されるため、固定です) 、ハッシュ値に従ってどのサーバーが割り当てられているかを決定し、各 IP リクエストが指定されたサーバーに割り当てられるようにします。これにより、ステートフル リクエストのステータスの整合性が保証され、ステータスの損失が発生しません。以下は nginx の設定です。参照してください:

upstream nginx.example.com  
    {   
             server 192.168.1.2:80;   
             server 192.168.1.3:80;  
             ip_hash;  
    }  
    server  
    {  
             listen 80;  
             location /  
             {  
                     proxy_pass  
                    http://nginx.example.com;  
             }  
 }

注: ip_hash このソリューションは確かにリクエストとステータスの整合性を保証できますが、大きな欠陥があります。 ip_hash ソリューションは、Nginx がフロントエンド サーバー (実際の IP を受け入れる) であることを確認する必要があります。nginx がフロントエンド サーバーではなく、ミドルウェア (中間サーバーなど) がある場合、nginx によって取得された IP アドレスは実際の IP ではありません。アドレスの場合、この ip_hash は意味がありません。

Nginx 関連の技術記事の詳細については、Nginx 使用法チュートリアル 列にアクセスして学習してください。

以上がnginx がセッションを共有する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。