Tomcatインスタンス間でセッションを共有する（スティッキーセッションを使用しない）

Question

3つのTomcatサーバーと、 'sticky sessions'を使用せずに要求をディスパッチするLoad Balancerがあります。

私はサーバー間でセッションのデータを共有したいと思います。私はそれらをDBに保存することを考えています。私はmemcachedを私のDBの前のレイヤーとして使用して、より速く要求を処理し、don't put my db under heavy loadにしたいと思います。

私は、セッションデータをDBに保存する前にmemcachedを使用するカスタマイズされたTomcat Managerを提供することを考えています。それは、透過的なやり方が見えない瞬間です。もう一度別のアプリサーバーに切り替える場合も同じです）。

これは良い解決策ですか、それとも良い方法がありますか？

Answer 1

私たちのアプリケーション（Weblogic、それは問題ではありません）と同様のことを行います。ここでは、ブラウザにCookieとして保存された一意のセッションキーがあります。そのキーは、各要求時に関連セッションデータをデータベースから復元するために使用されます。

この原則を使用して、ユーザーは何も気付かずにロードバランサを使用していつでも別のサーバーに切り替えることができます。これに加えて、ユーザーのセッションに関連するものはほとんど保存せず、ブラウザ内の多くの隠しフィールドで作業します（ロードバランサはURL暗号化とフォーム値保護をサポートしているため、安全面にあります...） 。

Answer 2

私はTerracotta Web Sessionsと思っています。

Answer 3

アプリケーションサーバー（あなたの場合はTomcat）の外にセッション状態を保存することは、大規模なWebサイトでは非常に一般的で推奨される構成です。これは通常、Shared Nothingというアーキテクチャスタイルを追求して行われます。

db、memcached、商用レプリケートキャッシュなど、さまざまな場所に状態を保存することができます。これらはすべてトレードオフのさまざまな組み合わせで動作します。個人的に、私はmemcachedで大きな成功を収めてきました。 Memcachedは非常に高速で安定しています。

一般に、N memcacheサーバーをN> 1、たとえば2とすると便利です。ユーザーがログインすると、アプリケーションサーバーはコインをひっくり返してユーザーの状態を示すサーバーストアを決定します。ブラウザに送信されるクッキーには、どのmemcacheサーバーからどのサーバーにルーティングするかを知る情報が含まれています。ブラウザからの後続の要求は、各要求時に適切なmemcacheサーバから状態を取得します。 memcacheサーバーが失敗した場合、ユーザーは新しいサーバーを再選択するために再度ログインする必要がありますが、それは非常にまれです。

Answer 4

データベース内のセッションを持続すると、スケーラビリティが制限されます。スケーラビリティがそれほど重要でない場合、これは有効なアプローチです（db + memcached）。

スティッキーセッションを使用しているときは、同時リクエストが必要です。 （並行して/同時に実行される）Ajaxリクエストは、（別のものではないために）別のTumcatsによって提供されるため、同時にセッションにアクセスします。セッションを変更する可能性のある同時要求がある限り、何らかの種類の同期/セッションロックを実装する必要があります。

おそらくこれはあなたにとって興味深いものです：私はmemcached-session-managerを作成し、最適なパフォーマンスと無制限のスケーラビリティの両方を目指しています。 memcached互換のバックエンド（memcachedb、membaseなど、memcachedなど）でも動作します。 もともとスティッキーセッションのアプローチのために作成されましたが、すでにbranch for nonsticky-sessionsが存在し、どのように動作しているかを示すsample appがあります。 今すぐthread on the mailing list on further improvements for nonsticky-sessionsがあります（同時リクエストの処理とシングルポイント障害の防止）。