困難を克服するプログラマー - 分散セッション問題の解決

[[339154]]

セッション セッションについて言えば、すべてのプログラマーはそれをよく知っており、多かれ少なかれプロジェクトで使用したことがあると思います。セッションという言葉は実際には抽象的な概念であり、Cookie のような明確な定義はありません。ほとんどのプログラマーがセッションについて話すとき、おそらくサーバー側でデータを保存するセッション オブジェクトを意味します。たとえば、ユーザーが正常にログインすると、このプログラムと同様に、ユーザー情報がセッションに保存されます。

セッション[ "UserName" ] = 新しいユーザー(); 
 
パブリッククラスUser {
公共  intユーザーID {取得;セット;}
パブリック文字列 UserName {get;セット;} 
 
 }

コンピュータ、特にネットワーク アプリケーションでは、セッションは「セッション」として定義され、クライアントとサーバー間のチャネル接続と見なすことができます。同じユーザーからのリクエストは同じセッションを使用します。ほとんどのアプリケーションでは、主にユーザー識別に使用されます。一般的に、サーバーはセッションを通じて各ユーザーのステータス情報を記録できます。最もよく使用されるサーバー側セッション オブジェクトについて説明します。

単一マシンセッション

セッションはサーバー上に保存されますが、これは非常に重要な概念です。つまり、サーバーのメモリを占有する必要があり、サーバーのメモリが使い果たされないようにするための解放メカニズム (LRU など) が必要になります。

プロジェクトの初期段階では、迅速にオンラインにするために、サーバーは 1 台のみで展開されることが多く、ユーザーのログイン状態を記録するためにセッション メカニズムがよく使用されていました。無理だなんて言わないでください。少なくともプロジェクトの初期段階では、このアプローチは最もシンプルで最速のソリューションです。プロジェクトが繰り返しアップグレードされ、ユーザー数が増え続けると、スタンドアロン システムがプロジェクトの最大のパフォーマンス ボトルネックになっていることがわかります。現時点では、ほとんどの建築家は水平拡張ソリューションを選択します。

実際、最終的には、システム パフォーマンスの向上は「分割」という言葉を中心に展開されます。データベースのパーティショニングであれ、新しいマイクロサービスであれ、それらは常にフィールドを中心に分割されます。

単一マシンセッションメカニズムを水平に拡張すると、セッションのアフィニティ（粘着性）をどのように解決するかという、解決しなければならない問題に直面します。

分散セッション

単一マシンシステムを分散システムに拡張すると、分散 CAP 理論における AP と CP の選択に直面することになります。

分散セッションの一貫性に関して言えば、主な問題は実際にはユーザー セッションのアフィニティを解決することです。同じユーザーのリクエストがセッション情報を正しく保存しているサーバーに到達することをどのように確認すればよいでしょうか?

セッションレプリケーション

最初の解決策は、セッション レプリケーションを使用することです。全体的なプロセスは非常に単純です。サーバーが 3 台あると仮定します。いずれかのサーバーでセッションが作成されると、そのセッションは他の 2 つのサーバーに同時に複製されます。このように、ユーザーのリクエストがどのサーバーに到達しても、対応するセッション データが存在します。

このソリューションの利点は、サーバーを任意のレベルで水平方向に拡張できることです。各サーバーはすべてのセッション情報を保持します。サーバーを追加するときは、すべてのセッション情報をそのサーバーにコピーするだけです。しかし、デメリットはもっと明白だ

• すべてのセッション情報は各サーバーに保存されるため、サーバーが占有するリソースが大幅に増加します。
• セッションの同期にはネットワーク帯域幅が必要です。最も重要なことは、非同期レプリケーションを使用すると、データが一時的に不整合になり、ユーザー アクセスが失敗する可能性があることです。

セッションレプリケーションは現在ほとんど使用されていません。

負荷分散ソリューション

サーバーを複数のサーバーに拡張する場合、最も一般的な解決策は、トラフィックの入り口にロード バランサーを追加することです。一般的な展開図は以下のとおりです

画像

ロード バランサが何らかの手段を使用してセッションの固定性を実現できる場合、分散セッションを実現できます。現在主流の nginx は、「hash_ip」アルゴリズムに基づいて同じ IP からのリクエストを特定のサーバーに固定できるため、同じ IP からのセッション リクエストは常に同じサーバーにリクエストします。

この方法はセッション同期方法よりもはるかに優れています。各サーバーは対応するセッション データのみを保存するため、メモリ リソースが大幅に節約され、サーバー間のデータ同期プロセスは発生しません。新しいサーバーを追加する場合は、ロードバランサーの構成を変更するだけで済み、サーバーの水平拡張を便利にサポートします。しかし、欠点もいくつかある

サーバーを再起動すると、対応するセッション情報が失われますが、これは一部の重要なビジネス シナリオでは許可されません。

サーバーの水平拡張にはロード バランサー構成の変更が必要であり、これにより以前のセッションが再配布され、一部のユーザーが正しいセッションにルーティングされなくなる可能性があります。

セッションの削除

現在広く使用されている分散セッション技術は、セッションデータを業務サーバーから完全に分離し、他の外部デバイスに別途保存するというものです。これらの外部デバイスは、マスター/スレーブ モード、マスター/スレーブ モード、さらにはクラスター モードを採用して高可用性を実現できます。たとえば、現在最も一般的に使用されているソリューションは、セッション データを Redis に保存することです。 Redis からのセッション データの読み取りと書き込みには一定のネットワーク時間が必要ですが、一般的なアプリケーションでは許容範囲内です。

このソリューションの利点は、全体的なアーキテクチャがより明確で柔軟になることです。アプリケーション サーバーの全体的なスケーラビリティでは、セッションの影響を考慮する必要がなくなり、セッションの問題は外部デバイスに転送されます。通常、パフォーマンスの問題を解決するには、インメモリ NOSql を使用できます。これらの外部デバイスには通常、マスタースレーブモードやセンチネルモード、さらにはクラスターを使用して大規模なデータサポート機能を提供できる、Redis などの対応する分散クラスターソリューションがあります。

俳優モデル

アクター モデルは、このユーザーの粘着性の問題をよりエレガントに解決します。オブジェクト認識機能が組み込まれています。簡単に言えば、同じキーに対するリクエストは常に正しいアクター インスタンスに到達できます。これが私たちが望んでいることではないでしょうか?さらに、アクター モデルはロックなしで同時実行の問題を処理できます。なぜ誰も使わないのでしょうか?さらに、acotr モデルはインプロセス キャッシュを利用できるため、LAN redis を要求する場合よりもネットワーク レイテンシが大幅に低くなります。

この記事はWeChat公開アカウント「建築家の修行の道」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、建築家の耕作道の公開アカウントまでご連絡ください。