スティッキーセッションとセッションの複製

Question

Tomcatでのセッションレプリケーションで粘着性セッションを使用する場合を評価しています。最初の評価から、セッションレプリケーションを有効にすると、1つのTomcatノードで開始されたセッションが他のすべてのTomcatノードにコピーされるため、セッションを継続するために粘着性セッションは必要ありません。 。

ただし、セッションの複製は一般的にスティッキーセッションで使用されているようです。そうしないと、リクエストが他のノードに行くたびにセッションIDを変更する必要があります。参照： http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#bind_session_after_crash_to_failover_node

スティッキーセッションを有効にする必要がある場合、セッションレプリケーションの実際の使用は何ですか？特定のセッションIDを使用したリクエストが常に同じノードに移動する場合、各ノードでセッションを不必要にコピーするからです。ノードがクラッシュする場合には有益かもしれませんが、それは頻繁には発生せず、セッションの複製を使用するだけでは過剰なように思えます。

Answer 1

唯一の本当の利点は、あまり考えずにTomcatインスタンスをシャットダウンできることだと思います。特に、これは今日、クラウドワールド（Amazon AWS Spotインスタンスを考えてください）で、ノードが本当に頻繁にオンとオフになることがあります。これに代わるものは、ノードの排水をサポートするまともなロードバランサーを購入することです。しかし、まともなロードバランサーは高価であり、排水には時間がかかります。

私が考えることができる別のシナリオは、アイテムが保管されているショッピングカートの（不十分な実装）です HttpSession そして、シャットダウンするには、ユーザーがそれらを再購入する必要があります（これにより、販売が失われる可能性があります）。

しかし、ほとんどの場合、あなたは正しいです - 粘着性のセッションとセッションの複製の両方を持つことの利点は非常に無視できます。

Answer 2

として ミンダス 以前に説明した：

Loadbalancingを使用する場合、Tomcatのいくつかのインスタンスがあり、負荷を分割する必要があります。

• 粘着セッションなしでセッションレプリケーションを使用している場合： Webアプリを使用しているユーザーが1人だけで、3つのTomcatインスタンスがあると想像してください。このユーザーはアプリにいくつかのリクエストを送信し、Loadbalancerはこれらのリクエストの一部を最初のTomcatインスタンスに送信し、これらのリクエストの他のいくつかを2番目のインスタンスに、その他を3番目に送信します。
• レプリケーションなしで粘着セッションを使用している場合： Webアプリを使用しているユーザーが1人だけで、3つのTomcatインスタンスがあると想像してください。このユーザーはアプリにいくつかのリクエストを送信し、ロードバランサーは3つのTomcatインスタンスのいずれかに最初のユーザーリクエストを送信し、セッション中にこのユーザーが送信した他のすべてのリクエストは同じTomcatインスタンスに送信されます。これらのリクエスト中に、このTomcatインスタンス（使用されているTomcatインスタンス）をシャットダウンまたは再起動すると、ロードバランサーは残りのリクエストをまだ実行している他のTomcatインスタンスに送信しますが、セッションレプリケーションを使用していないため、受信するインスタンスTomcat残りのリクエストにはユーザーセッションのコピーがありません。このTomcatでは、ユーザーはセッションを開始します。ユーザーはセッションを失い、Webアプリがまだ実行されていますが、Webアプリから切断されます。
• セッションレプリケーションでスティッキーセッションを使用している場合： Webアプリを使用しているユーザーが1人だけで、3つのTomcatインスタンスがあると想像してください。このユーザーはアプリにいくつかのリクエストを送信し、ロードバランサーは3つのTomcatインスタンスのいずれかに最初のユーザーリクエストを送信し、セッション中にこのユーザーが送信した他のすべてのリクエストは同じTomcatインスタンスに送信されます。これらのリクエスト中に、このTomcatインスタンス（使用されているTomcatインスタンス）をシャットダウンまたは再起動すると、ロードバランサーは残りのリクエストを実行している他の1つのTomcatインスタンスに送信します。ユーザーセッションのコピーで、ユーザーはセッションを維持します。ユーザーは、切断されずにWebアプリを閲覧し続けます。Tomcatインスタンスのシャットダウンはユーザーナビゲーションに影響を与えません。

Answer 3

jboss 5.xの構成の問題を「すべて」のベース構成でMod_jkを明確にするためだけです。 workers.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.xmlに設定する必要があります cacheMode パラメーターに LOCAL.

通常、粘着性セッションシナリオでは、セッションの複製に必要なかなりの量のI/O操作に接続された追加のオーバーヘッドが必要ないため、セッションの複製は必要ありません。

実際、Stickyセッションを使用しても、「すべて」構成でJBOSSを実行する必要はありません。「デフォルト」または「標準」ベースの構成を使用する場合があります。

しなければならない唯一のことは、$ jboss_home/server/your_node_name/deploy/jbossweb.sar/server.xmlの変更です。

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">