30

Tomcat のセッション レプリケーションでスティッキー セッションを使用するケースを評価しています。私の最初の評価から、セッション レプリケーションを有効にすると、1 つの tomcat ノードで開始されたセッションが他のすべての tomcat ノードにコピーされるため、セッションを継続するためにスティッキー セッションは必要なく、要求は任意のノードで取得できると考えました。 .

しかし、セッション レプリケーションは一般にスティッキー セッションで使用されるようです。それ以外の場合は、リクエストが他のノードに送信されるたびにセッション ID を変更する必要があります。参照: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node

スティッキーセッションを有効にする必要がある場合、セッションレプリケーションの実際の使用法を誰か説明できますか? 特定のセッションIDを持つリクエストが常に同じノードに送信される場合、各ノードでセッションを不必要にコピーすることになるためです。ノードがクラッシュした場合には有益かもしれませんが、それは頻繁に発生するわけではなく、そのためだけにセッション レプリケーションを使用するのはやり過ぎのように思えます。

4

3 に答える 3

83

ミンダスが以前に説明したように：

ロードバランシングを使用する場合、Tomcat の複数のインスタンスがあり、負荷を分割する必要があることを意味します。

  • スティッキー セッションなしでセッション レプリケーションを使用している場合: Web アプリを使用しているユーザーが 1 人だけで、Tomcat インスタンスが 3 つあるとします。このユーザーがアプリにいくつかのリクエストを送信すると、ロードバランサーはこれらのリクエストの一部を最初の tomcat インスタンスに送信し、これらのリクエストの他の一部を 2 番目のインスタンスに送信し、残りを 3 番目のインスタンスに送信します。
  • レプリケーションなしでスティッキー セッションを使用している場合:Web アプリを使用しているユーザーが 1 人だけで、Tomcat インスタンスが 3 つあるとします。このユーザーがアプリにいくつかのリクエストを送信すると、ロードバランサーは最初のユーザー リクエストを 3 つの tomcat インスタンスの 1 つに送信し、このユーザーがセッション中に送信した他のすべてのリクエストは同じ tomcat インスタンスに送信されます。これらのリクエスト中に、この tomcat インスタンス (使用されている tomcat インスタンス) をシャットダウンまたは再起動すると、ロードバランサーは残りのリクエストを、まだ実行中の別の tomcat インスタンスに送信します。残りのリクエストにはユーザー セッションのコピーがありません。この tomcat では、ユーザーはセッションを開始します。ユーザーはセッションを失い、Web アプリはまだ実行されていますが、Web アプリから切断されます。
  • スティッキー セッション WITH セッション レプリケーションを使用している場合:Web アプリを使用しているユーザーが 1 人だけで、Tomcat インスタンスが 3 つあるとします。このユーザーがアプリにいくつかのリクエストを送信すると、ロードバランサーは最初のユーザー リクエストを 3 つの tomcat インスタンスの 1 つに送信し、このユーザーがセッション中に送信した他のすべてのリクエストは同じ tomcat インスタンスに送信されます。これらのリクエスト中に、この tomcat インスタンス (使用されている tomcat インスタンス) をシャットダウンまたは再起動すると、ロードバランサは残りのリクエストを、まだ実行中の別の tomcat インスタンスに送信します。ユーザー セッションのコピー、その後ユーザーはセッションを継続します。ユーザーは切断されることなく Web アプリを閲覧し続けます。Tomcat インスタンスのシャットダウンはユーザー ナビゲーションに影響しません。
于 2012-06-15T06:09:58.587 に答える
10

唯一の本当の利点は、あまり考えずに Tomcat インスタンスをシャットダウンできることだと思います。特にこれは、ノードが非常に頻繁にオンとオフを繰り返す今日のクラウドの世界 (Amazon AWS スポット インスタンスを考えてください) に当てはまります。これに代わる方法は、ノードのドレインをサポートする適切なロード バランサーを購入することです。しかし、適切なロード バランサーは高価であり、ドレインには時間がかかります。

私が考えることができる別のシナリオは、アイテムが に保持され、HttpSessionシャットダウンするとユーザーがそれらを再購入する必要がある (これは販売の損失につながる可能性が高い) ショッピング カート (の貧弱な実装) です。

しかし、ほとんどの場合、あなたの言うとおりです。スティッキー セッションとセッション レプリケーションの両方を使用する利点は、ほとんどありません。

于 2011-06-17T22:04:09.863 に答える
0

mod_jk を使用した「すべての」基本構成での JBoss 5.X の構成の問題を明確にするためです。worker.properties ファイルでのスティッキー セッションの設定

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

セッションの複製は妨げられません。JBoss でセッション複製をオフにするには、$JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xmlcacheModeパラメーターを設定する必要があります。 LOCAL.

通常、スティッキー セッションのシナリオでは、セッションのレプリケーションに必要な大量の I/O 操作に関連する追加のオーバーヘッドが発生しないようにするため、セッションのレプリケーションは必要ありません。

実際、スティッキー セッションを使用する場合、JBoss を「すべて」の構成で実行する必要はなく、「デフォルト」または「標準」ベースの構成を使用できます。

$JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml を変更するだけです。

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">
于 2012-03-30T19:18:22.573 に答える