4

Tomcat (ここではバージョン 5) は、セッション情報をメモリに保存します。クラスタリングの際、この情報は定期的にクラスタ内の他のサーバーにブロードキャストされ、同期が保たれます。データベース ストアを使用してセッションを永続化することはできますが、この情報は定期的にのみ書き込まれ、メモリ内セッションを実際に置き換えるのではなく、実際には障害回復のためにのみ使用されます。

スティッキー セッションを使用したくない場合 (残念ながら、構成では許可されていません)、セッションが同期しなくなるという問題が発生します。

他の言語では、Web フレームワークにより、データベースをプライマリ セッション ストアとして使用できるようになる傾向があります。これによりスケーリングの問題が発生する可能性がありますが、セッション管理が非常に簡単になります。この方法でTomcatにセッション用のデータベースを使用させる方法があるかどうか疑問に思っています(技術的には、これによりTomcat server.xmlでのクラスタリング構成の必要性もなくなります)。

4

4 に答える 4

3

必ず方法があります。スティッキーセッションに強く投票しますが、サーバー/データベースの負荷を大幅に節約できます（何かが失敗しない限り）...

http://tomcat.apache.org/tomcat-5.5-doc/config/manager.htmlには、Tomcat の SessionManager 構成とセットアップに関する情報があります。正確な要件によっては、独自のセッション マネージャーを実装する必要がある場合がありますが、この出発点が役立つはずです。

于 2008-09-17T12:09:50.867 に答える
2

私は常にRailsのセッション手法のファンでした.セッションを(圧縮+暗号化+署名付き)ユーザーのCookieに保存します. そうすれば、心ゆくまで負荷分散を行うことができ、スティッキーセッションやセッションデータのデータベースへのアクセスなどを心配する必要はありません.Javaアプリで何らかのソートなしで簡単に実装できるかどうかはわかりません.セッションアクセスコードの書き換えの。とにかく片思い。

于 2010-07-29T01:15:09.303 に答える
2

Terracottaを見てください。アプリケーションを大幅に再設計することなく、スケーリングの問題に対処できると思います。

于 2008-09-17T12:08:53.210 に答える
2

もう 1 つの代替手段は、memcached-session-managerです。これは、tomcat 6.x / 7.x 用の memcached ベースのセッション フェイルオーバーおよびセッション レプリケーション ソリューションです。スティッキー セッションと非スティッキー セッションの両方をサポートします。

このプロジェクトを作成したのは、最高のパフォーマンスと信頼性を得て、Tomcat ノードと memcached ノードを追加するだけでスケールアウトできるようにするためです。

于 2011-04-12T08:19:39.987 に答える