統合されたセッション共有の問題

2.1 クライアント Cookie の保存

概要

Cookie で暗号化された方法でクライアント側に保存されるため、セッション情報がクライアント側に書き込まれ、送信されるたびにサーバー側にかかる負荷が軽減されます。ブラウザ経由でサーバーに再度アクセスします。クラスター内の 2 つのサーバーで 2 つのリクエストが完了した場合でも、セッション共有に到達する可能性があります。

このソリューションの利点は、セッション情報をサーバー側に保存する必要がないため、サーバーへの負荷が大幅に軽減されることです。もう 1 つの利点は、セッション内の 2 つ以上のリクエストをクラスター内の複数のサーバーで完了できるため、単一点障害が回避されることです。現在、タオバオはこのソリューションを採用しています。

いくつかの欠点があります。第一に、HTTP 情報ヘッダーの長さの制限により、クッキーにユーザー情報の一部しか保存できなくなります。第二に、セッション情報を暗号化するために追加の作業が必要になります。このようにして、Web サイトの第 2 レベルのドメイン名にアクセスするたびに、Cookie の形式で保存されたセッション情報が http 情報ヘッダーに含まれ、最終的に一定量の帯域幅を占有することになります。このメソッドはクライアントに情報を保存しますが、ユーザーは完全に Cookie を無効にしたり削除したりすることができますが、あまり信頼性が高くありません。

2.2 サーバー間のセッション同期

はじめに

マスター/スレーブサーバーアーキテクチャを使用すると、ユーザーがマスターサーバーにログインすると、セッション情報がスクリプトまたはデーモンプロセスを通じて各スレーブサーバーに転送されます。ユーザーが他のスレーブサーバーにアクセスすると、セッション情報を読み取ることができます。

デメリット: 速度が遅い、不安定など。また、セッション情報の送信がマスター→スレーブの一方向の場合、メインサーバーがダウンすると他のサーバーが取得できなくなるなどのリスクがあります。セッション情報

2.3 クラスターの使用セッションの統合管理

はじめに

他のアプリケーションがセッション情報をセッションクラスターサーバーグループに保存するためのクラスターを提供します。アプリケーション システムがセッション情報を必要とする場合、セッション クラスター サーバーからセッション情報を直接読み取ります。現在、そのほとんどは Memcache を使用してセッションを保存しています。

Memcache を使用してセッション共有を実装するには、現在 2 つの一般的な実装ソリューションがあります。これらの 2 つのソリューションを以下に主に紹介します。

2.3.1 Filter メソッドを使用する

このメソッドは、filter メソッドを使用して httpRequest オブジェクトを再パッケージ化し、me​​mcached クライアントを追加します。また、フィルターを設定するだけで使用できるという利点があります。クライアント上に実装されるため、構成は柔軟であり、サーバーに依存しません。サーブレットをサポートする任意のコンテナーにデプロイできます。

2.3.2 memcached-session-manager (MSM)

memcached-session-manager (一般的に MSM として知られる) は、分散 Tomcat 環境におけるセッション共有の問題を解決するために使用されるオープン ソース ソリューションです。その実装原理は、サーバー上に Tomcat プラグインとしてデプロイし、サーブレット コンテナ コード内のセッション関連のコードを変更し、memcached に接続し、memcached でセッションを作成および更新することです。 MSM には次の機能があります:

Tomcat6、Tomcat7 をサポート

スティッキーセッションと非スティッキーセッションをサポート

単一障害点がない

Tomcat フェイルオーバーを処理できる

memcached フェイルオーバーを処理できる

プラグインセッションのシリアル化

が可能応答速度を向上させるためのセッションの非同期保存

セッションが変更された場合にのみ、セッションは memcached に書き戻されます

JMX 管理と監視

MSM (memcached-session-manager) は、Value (Tomcat) を使用して tomcat6 と tomcat7 をサポートしますバルブ) を使用してリクエストを追跡します。 Request リクエストが到着すると、セッションは memcached からロードされ、Request リクエストが終了すると、セッション共有の目的を達成するために Tomcat セッションが memcached に更新されます。

利点: 開発者はセッション共有の問題を考慮する必要がなくなり、プログラム開発に集中して通常のセッションと同じように使用できます。コードを明示的に記述する必要はなく、コードを使用するようにサーバーを構成するだけで済みます。

欠点: セッションポリシーを変更したい場合は、各サーバーのサーブレットコンテナを再デプロイする必要があります。

詳細については、http://code.google.com/p/memcached-session-manager/

2.4 データベースへのセッションの永続化

はじめに

このセッション共有方法では、セッション情報が保存されます。データベースを使用すると、他のアプリケーションがデータベースからセッション情報を確認できます。このソリューションを使用するときに現在使用されているデータベースは通常 mysql です。

データベースを使用してセッションを共有するソリューションには、ある程度の実用性がありますが、次の欠点もあります。まず、セッションの同時読み取りと書き込みがデータベース内で完了するため、MySQL に比較的高いパフォーマンスが必要です。セッション削除ロジック コードを追加実装するため、つまりデータベース テーブルのセッション情報を定期的に更新および削除するため、作業負荷が増加します

2.5 ユーザーのセッションが 1 つのサーバーで定期的に完了できるように負荷分散サーバーを構成します。 1 つのサーバーがダウンした後、ユーザーのリクエストはバランシング サーバーを通じて透過的に転送されます。このとき、バックアップ セッション情報はスレーブから読み取られる必要があります。

以上が統合されたセッション共有の問題の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。