分散システムにおけるセッション共有の 5 つの方法

[[272319]]

1. NFSベースのセッション共有

NFS は Net File System の略称で、Unix ネットワーク ホスト間のディレクトリ共有の問題を解決するために Sun によって最初に開発されました。

このソリューションは実装が最も簡単で、二次的な開発をあまり必要としません。共有ディレクトリ サーバーを各チャネル サーバーのローカル セッション ディレクトリにマウントするだけで済みます。欠点は、NFS が複雑なセキュリティ メカニズムとファイル システムに依存しているため、特にセッションなどの同時読み取りと書き込みが多い小さなファイルの場合、同時実行効率が高くないことです。共有ディレクトリ サーバーの io-wait が高すぎるため、最終的にはフロントエンド WEB アプリケーションの実行効率が低下します。

2. データベースに基づくセッション共有

最初の選択肢はもちろん有名な MySQL データベースであり、セッション操作の読み取りと書き込みの効率を向上させるためにメモリ テーブル Heap を使用することをお勧めします。このソリューションは非常に実用的であり、広く使用されていると思います。欠点は、セッションの同時読み取りおよび書き込み機能が MySQL データベースのパフォーマンスに依存することです。同時に、データ テーブルからセッション レコードを定期的に更新および削除できるように、セッション削除ロジックを自分で実装する必要があります。同時実行性が高すぎると、テーブル ロックが発生しやすくなります。行レベルのロックを備えたテーブル エンジンを選択することもできますが、セッションを保存するためにデータベースを使用するのは、まだ少しやり過ぎであることを認めざるを得ません。

3. クッキーに基づくセッション共有

このソリューションは私たちにとって馴染みのないものであるかもしれませんが、大規模な Web サイトでは現在でも一般的に使用されています。原則としては、サイト全体のすべてのユーザーのセッション情報を暗号化してシリアル化し、それをクッキーの形式でルートドメイン名 (.host.com など) に均一に埋め込むことです。ブラウザを使用してルートドメイン名の下にあるすべての第 2 レベル ドメイン サイトにアクセスすると、ドメイン名に対応するすべての Cookie コンテンツの特性が渡され、複数のサービス間でユーザーの Cookie セッションの共有アクセスが実現されます。

このソリューションの利点は、追加のサーバー リソースを必要としないことです。欠点は、http プロトコル ヘッダーの長さの制限により、保存できるユーザー情報が少量だけであることです。同時に、Cookie ベースのセッション コンテンツは安全に暗号化および復号化される必要があります (プレーン テキストの暗号化と復号化には DES、RSA などを使用し、偽造防止認証には MD5、SHA-1 などのアルゴリズムを使用するなど)。さらに、ブラウザは現在のドメイン名の下にあるリソースを要求するときにローカル Cookie を http ヘッダーに添付してサーバーに渡すため、一定量の帯域幅リソースも消費します。

4. Memcache に基づくセッション共有

Memcache は、Libevent マルチチャネル非同期 I/O テクノロジーに基づくメモリ共有システムです。シンプルなキー + 値のデータ ストレージ モードにより、コード ロジックが小さく効率的になるため、同時処理機能において絶対的な利点があります。私が経験したプロジェクトでは、1 秒あたり平均 2000 クエリを達成しましたが、サーバーの CPU 消費量は依然として 10% 未満でした。

Memcache のメモリ ハッシュ テーブルに固有の Expires データの有効期限と削除のメカニズムがセッション有効期限のメカニズムと一致しているため、期限切れのセッション データを削除するコードの複雑さが軽減されることも特筆に値します。 「データベース ベースのストレージ ソリューション」と比較すると、このロジックだけでデータ テーブルに大きなクエリ負荷が発生します。

5. Redis ベースのセッション共有