アプリケーションレベルのスコープでのカウンター状態のクラスタリング/複製

Question

8ノードクラスタ全体でシーケンス/カウンタを複製する必要があります。これは、各http要求がgetNextIntAndIncrement（）などの呼び出しによってシーケンス内の次の値を受け取ることを意味します。この場合、シーケンスの状態はすべてのサーバー間で同期されます。明確にするために、これはセッションではなくアプリケーション/グローバルスコープに存在する必要があります。私はそれがひどいアイデアのように聞こえ、間違いなくボトルネックにつながることを知っていますが、これは要件です。

私の質問は、最善の解決策は何ですか？ステートフルセッションBeanを見てきましたが、それらは1つのクライアントだけのために設計されているようです。データベースシーケンスを検討しました。また、テラコッタクラスタリングについても見てきました。シーケンスデモ http://www.terracotta.org/web / display / orgsite / Recipe？recipe = sequencer ただし、J2EEソリューションが存在する場合は、サードパーティのソリューションを避けたいと思います。 Weblogic 8.1を使用しています。

Answer 1

一部のJava EEベンダーは、サードパーティ製品を既に特定しているため、キャッシュソリューション（WebSphereのObject Gridなど）を分散していますが、移植可能な標準が存在するとは思いません。

DBソリューションの何が問題になっていますか？ロックが必要になることは明らかなので、DBに任せてみてください。私の推測では、真のインクリメンタル値が本当に必要な場合、値が失われないなど、他のデータベース値とのトランザクション関係が重要になるため、DBを使用します。

絶対的なシーケンシャル値の必要性を緩和できる場合（つまり、ギャップを許可する場合）、一連の数値を分割して、競合を大幅に減らすことができます。連続した値が本当に必要であり、ギャップがない場合、インスタンス間のある程度のロックの必要性に賛成です-2番目の「スレッド」を許可することはできません。 「コミット」するまで新しいシーケンス番号を取得します。現在の使用。奇数のシーケンス番号を失う余裕があれば、はるかに良い結果が得られます。または、インスタンス間で番号付けスキームを独立させることができれば、はるかに良い位置にいます。たとえば、サーバーa、b、c ...の名前には、ID a001、a002、b001、c001、c002などがあります。

Answer 2

データベースシーケンスは、特に高度にシリアル化されたトランザクションを使用して要求する場合、最も決定的な結果をもたらす可能性が高いと思います。

ただし、このようなことを行うことの妥当性について真剣に疑問を呈しますが、それは私の2セントです。

Answer 3

この質問のタグにweblogicがあります-weblogicはクラスターシングルトンを許可します。例えばフェールオーバーをサポートするクラスターごとに1つのインスタンス。

これは要件を満たしている必要があります：

http：// e-docs .bea.com / wls / docs100 / javadocs / weblogic / cluster / singleton / SingletonService.html