分散システムにおけるセッション処理

サーバー独立セッション

以下に示すように:
サーバー非依存セッションでは、各ユーザー リクエストを同じアプリケーション サーバー上で操作する必要があり、負荷分散サーバーはユーザーのリクエストを毎回同じアドレスのサーバーに送信する必要があります。
最初のユーザーが初めてアクセスするサーバー No. 1 は、ユーザーのセッション全体を通じて負荷分散サーバーによってサーバー No. 1 に誘導される必要があります。他のサーバーではユーザー No.1 のセッション情報は保存されません。

今の負荷分散サーバーはこの機能(nginx)が一般的です

しかし、次のような状況が起こった場合

このときサーバー1号がダウンしていると、負荷分散サーバーはユーザー1号を迂回させますしかし、ユーザーはサーバー No. 2 と No. 3 にセキュア コンテキストを持っていません。サーバーはユーザーに再度ログインするように通知します。このユーザーエクスペリエンスは間違いなく影響を受けます。そして、ユーザーデータの損失を引き起こす可能性が非常に高くなります。

各サーバーはすべてのセッションを保持します

各サーバーはすべてのユーザー セッションを保持します。これは、アプリケーション サーバー間のセッション同期の問題に関連しており、リアルタイム要件が比較的高くなります。この方法では、以下の図に示すように、上記のサーバーの独立したセッションで発生する問題を回避できます。

利点

この方法では、最初の状況が発生した場合でも、番号 1 がサーバーに保存されます。 2 および 3. セッション情報。ロード バランシング サーバーに障害が発生し、ユーザー 1 がサーバー 2 および 3 にリダイレクトされると、サーバーはユーザー 1 のセキュリティ コンテキストが存在することも認識し、再度ログインする必要なくアクセスを継続できます。 。

欠点

しかし、この方法には欠点もあります。つまり、アプリケーションサーバーのセッション同期のリアルタイム要件が比較的高く、追加のクロスバンドオーバーヘッドが発生し、セッションがリモートで変更されると同期が困難になります。必須。セッション内の情報量が比較的多い場合、かなりのメモリを消費します。

サーバー共有セッション

サーバー共有セッション情報:

利点

各ユーザーのセッション情報はアプリケーションの外部の別のサーバー (データベースまたは KV ストレージ サービスなど) に保存されるため、アプリケーションサーバーは各ユーザーのセッション情報を保存する必要がないため、メモリのオーバーヘッドが大幅に節約されます。

異なるアプリケーションサーバーがセッション情報を使用する必要がある場合、共有セッションサーバーに移動して情報を取得します。

この方法では、負荷分散サーバーはユーザーを固定サーバーに割り当てる必要がなく、セッション情報が変更されたときにアプリケーションサーバーが共有サーバーに移動して変更することができます。情報。

デメリット

共有サーバーまたは共有サーバークラスターに問題が発生すると、ユーザーに多大な影響が及びます

セッションデータをCookieで送信

ユーザー情報をCookieに保存することで不安定要因を排除できますが、 Cookie にはセキュリティ上の危険性が依然として潜んでいますし、Cookie には長さの制限もあります。

以上、分散システムにおけるセッションの処理をその側面も含めて紹介しましたが、PHP チュートリアルに興味のある方の参考になれば幸いです。