この記事では、PHP セッションに関連する知識を紹介します。まず、このセッション共有ソリューションが登場する理由から始めましょう。困っている友達に役立つことを願っています~
最初に理解してください。このセッション共有ソリューションは登場しますか?
インターネット企業のプロジェクトはマイクロサービスと分散環境で構築されているため、プロジェクトは複数または多数のサーバー クラスターにデプロイされる場合があります。ユーザーはセッションを持っています。たとえば、ユーザーがプロジェクトにログインします。一般に、大企業のプロジェクトにはリバース プロキシ用に Nginx が使用されています。
ここでは、Nginx で一般的に使用されるいくつかのリバース プロキシ戦略を簡単にリストしてみましょう:ポーリング戦略、重み比率戦略、ip_hash 戦略、およびカスタマイズ可能な戦略、
Nginx のリバース プロキシでは、プロキシの下では、ユーザーのリクエストは通常、異なるサーバーに分散されます。ユーザーのリクエストがリクエストのサーバー A に保存されている場合、ユーザーのセッション ID はサーバー上の JVM の ConcurrentHashmap に保存されます。sessionID をキーとして使用します。
ただし、この時点でユーザーがリクエストしたサービス モジュールをサーバー B に呼び出す必要がある場合、ユーザーがリクエストを開始するとき、この時点ではユーザーのセッション ID がサーバー B に保存されていないため、ユーザーは再度ログイン操作を行うように求められます。また、ユーザーが最初は注文操作を完了したかったのに、何度もログインしてしまったという状況が発生する可能性もあります。
したがって、セッション共有ソリューションは、分散環境やマイクロサービス システムでは特に重要です。 [推奨学習: "
PHP ビデオ チュートリアル"]解決策 1: Nginx ベースの ip_hash ロード バランシング
詳細な実装:
使用可能な独自のサーバーに応じて、Nginx.conf ファイルに対応する変更を加える必要があります
upstream backend{ ip_hash; server 192.168.128.1:8080 ; server 192.168.128.2:8080 ; server 192.168.128.3:8080 down; server 192.168.128.4:8080 down; } server { listen 8081; server_name test.csdn.net; root /home/system/test.csdn.net/test; location ^~ /Upload/upload { proxy_pass http://backend; } }
この実装の長所と短所:
# #解決策 2: Tomcat に基づくセッション レプリケーション
この解決策は、実際には、ユーザーが要求したときに生成されたセッション ID をシステム内のすべてのサーバーにコピーして、ユーザーが要求したときに確実にサーバー A がサーバー B 上のモジュールを呼び出す場合、サービス B にもユーザーのセッション ID があることを確認できるため、ユーザーは再度ログインを求められなくなります。それで問題は解決します。 特定のコードでセッション レプリケーションを実装するにはどうすればよいですか?セッション レプリケーションを使用する利点と欠点:
解決策 3: キャッシュされたセッションの統合キャッシュとして Redis を使用する
この解決策は、実際には、ユーザーがリクエストするたびに生成される sessionID を Redis サーバーに置くことです。次に、Redis の特性に基づいて有効期限メカニズムを設定し、設定した Redis のセッション有効期限内にユーザーが再度ログインする必要がないようにします。 コードの実装方法: #Redis を使用してセッション共有を実装する利点と欠点: 解決策 4: Cookie を結合する実際、Cookie にセッションを含めることもできます。ユーザーがリクエストするたびに、その Cookie がリクエストに入れられるため、これにより、すべてのセッションが確実に行われるようになります。ユーザーがリクエストを行うときに、分散環境でユーザーが 2 回ログインしないことを保証できます。
以上がPHP セッション共有のための 4 つのソリューションについて話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。