PHP セッション共有のための 4 つのソリューションについて話しましょう

この記事では、PHP セッションに関連する知識を紹介します。まず、このセッション共有ソリューションが登場する理由から始めましょう。困っている友達に役立つことを願っています~

最初に理解してください。このセッション共有ソリューションは登場しますか?

インターネット企業のプロジェクトはマイクロサービスと分散環境で構築されているため、プロジェクトは複数または多数のサーバー クラスターにデプロイされる場合があります。ユーザーはセッションを持っています。たとえば、ユーザーがプロジェクトにログインします。一般に、大企業のプロジェクトにはリバース プロキシ用に Nginx が使用されています。

ポーリング戦略、重み比率戦略、ip_hash 戦略、およびカスタマイズ可能な戦略、

Nginx のリバース プロキシでは、プロキシの下では、ユーザーのリクエストは通常​​、異なるサーバーに分散されます。ユーザーのリクエストがリクエストのサーバー A に保存されている場合、ユーザーのセッション ID はサーバー上の JVM の ConcurrentHashmap に保存されます。sessionID をキーとして使用します。

ただし、この時点でユーザーがリクエストしたサービス モジュールをサーバー B に呼び出す必要がある場合、ユーザーがリクエストを開始するとき、この時点ではユーザーのセッション ID がサーバー B に保存されていないため、ユーザーは再度ログイン操作を行うように求められます。また、ユーザーが最初は注文操作を完了したかったのに、何度もログインしてしまったという状況が発生する可能性もあります。

したがって、セッション共有ソリューションは、分散環境やマイクロサービス システムでは特に重要です。 [推奨学習: "

"]解決策 1: Nginx ベースの ip_hash ロード バランシング

実際には、要求された IP アドレスがどの程度になるかです。利用可能な各サーバーからモデルを取得し、Nginx のリバース プロキシを通じて対応するサーバーにリクエストを配布します。 (ここでは、使用可能なサーバーが配列に入れられます。モジュロを取得して得られた結果が の場合、リクエストはサーバー配列内の添え字を持つサーバーに割り当てられます。)

詳細な実装:

使用可能な独自のサーバーに応じて、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 に基づくセッション レプリケーション

セッション レプリケーションを使用する利点と欠点:

解決策 3: キャッシュされたセッションの統合キャッシュとして Redis を使用する

実際、Cookie にセッションを含めることもできます。ユーザーがリクエストするたびに、その Cookie がリクエストに入れられるため、これにより、すべてのセッションが確実に行われるようになります。ユーザーがリクエストを行うときに、分散環境でユーザーが 2 回ログインしないことを保証できます。

以上がPHP セッション共有のための 4 つのソリューションについて話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。