Tomcatインスタンス間でセッションを共有する（スティッキーセッションを使用せずに）
3つのTomcatサーバーと、「 スティッキーセッション 」を使用せずにリクエストをディスパッチするロードバランサーを用意します。
サーバー間でセッションのデータを共有したいので、それらをDBに保持することを考えています。 memcached をDBの前のレイヤーとして使用して、リクエストをより高速に処理し、 DBに大きな負荷をかけないでください にします。
セッションデータをDBに取得/永続化する前に、memcachedを使用するカスタマイズされたTomcat Managerを提供することを考えています。現時点では、透過的な方法が見当たらないためです（つまり、別のアプリサーバーに切り替えた場合に備えて、再度管理してください）。
これは良い解決策ですか、それともより良いアプローチがありますか？
データベースにセッションを永続化すると、スケーラビリティが制限されます。スケーラビリティがそれほど重要でない場合は、これ（db + memcached）が有効なアプローチです。
非スティッキーセッションを使用するときに覚えておく必要があることの1つは、同時リクエストです。 ajax-requests（並行して/同時に実行される）それらは（非粘着性のために）異なるtomcatによって処理されるため、同時にセッションにアクセスします。セッションを変更する可能性のある同時リクエストがある限り、何らかの同期/セッションロックを実装する必要があります。
おそらくこれはあなたにとって興味深いことです：私は最適なパフォーマンスと無制限のスケーラビリティの両方を目的として memcached-session-manager を作成しました。 memcached互換のバックエンド（memcachedb、membaseなど、またはmemcachedのみ）で動作します。もともとはスティッキーセッションアプローチ用に作成されましたが、すでに 非スティッキーセッション用のブランチ が存在し、 サンプルアプリ がどのように機能するかを示しています。現在、 非スティッキーセッションのさらなる改善に関するメーリングリストのスレッド （同時リクエストの処理と単一障害点の防止）があります。
セッション状態をアプリサーバー（この場合はTomcat）の外部に保存することは、大規模なWebサイトでは非常に一般的で推奨される構成です。これは通常、 Shared Nothing と呼ばれるアーキテクチャスタイルを追求して行われます。
状態は、db、memcached、商用複製キャッシュなど、いくつかの異なる場所に保存できます。これらはすべて、トレードオフのさまざまな組み合わせで機能します。個人的には、memcachedで大きな成功を収めています。 Memcachedは非常に高速で安定しています。
一般に、私は単純さを選択し、N> 1、たとえば2のN memcacheサーバーを使用します。ユーザーがログインすると、アプリサーバーはコインを投げて、ユーザーの状態を保存するサーバーを決定します。ブラウザに送信されるCookieには、それ以降にルーティングするmemcacheサーバーを知るための情報が含まれています。ブラウザからの後続のリクエストは、リクエストごとに適切なmemcacheサーバーから状態をフェッチします。 memcacheサーバーに障害が発生した場合、アプリサーバーが新しいサーバーを再選択するため、ユーザーは再度ログインする必要がありますが、これは非常にまれです。
アプリケーション（Weblogicですが、それは問題ではありません）でも同様のことを行います。ここでは、ブラウザーにCookieとして格納されている一意のセッションキーがあります。そのキーは、データベースから関連するセッションデータを復元するために、各リクエストで使用されます。
この原則を使用すると、ユーザーが何も気付かずに、ロードバランサーを使用していつでも別のサーバーに切り替えることができます。それに加えて、ユーザーのセッションに関連するものをほとんど保存せず、ブラウザーの多くの非表示フィールドを操作します（ロードバランサーはURL暗号化とフォーム値保護をサポートしているため、安全を確保しています...） 。
Terracotta Web Sessions があなたが望むものだと思います。