5

問題を考えてみましょう:

ステートレス コンテンツを提供する Web アプリケーションを備えた n 個の Tomcat ノードがあります。たとえば、最初の 1000 件のリクエストに対してアプリケーションは「a」で応答し、次の 10000 件では「b」、残りのリクエストでは「c」で応答する必要があります。

最初にメッセージングを検討しました。アプリケーションはいくつかのストレージから合計提供カウントを取得します-> nより小さい場合はコンテンツ「a」を提供します->コンテンツが提供されると、アプリケーションはメッセージを送信します->メッセージが消費されます->合計提供カウントが増加します一部のストレージ -> ... ただし、この場合、メッセージが配信されたイベントとストレージのカウンターの増分との間のわずかな (またはピーク読み込み時間の巨大な) 遅延のために、オーバーシュートの可能性が非常に高くなります。

次に、カウンターを一種の共有セッションに保存するように memcached-session-manager をセットアップすることを検討しました。しかし、これは私の単純なケースではかなり重いようです。

複数のJVMインスタンスが相互に通信できる簡単な方法があるかどうかを誰かが提案してもらえますか(私の場合には何が当てはまりますか)?

4

3 に答える 3

2

絶対に正しい必要があり、遅延を望まない場合は、 RedisまたはHazlecastが最適なオプションだと思います。特に Redis は、操作のようなアトミック カウントを備えているためです。理論的には memcache でも同じことができますが、Redis はまさにこのユース ケース (統計カウンター) 向けに設計されています。

H2のようなメモリ内データベースを使用するか、PostgresテーブルをunloggedRDBMSに適用できるものに設定して、疑似インメモリテーブルで安全ではないものを保持することもできます。RDBMS の厄介な点は、すべての RDBMS でアップサートが一貫してサポートされていないことです。MERGE

于 2013-10-05T15:05:35.250 に答える
1

まず、Tomcat インスタンス間でセッションを共有できます。リクエストを受信したTomcatサーバーは、基本的にそのセッションの複製を他のすべてのTomcatサービスに送信します。

この要求を駆り立てている表現されていないニーズがあると思わずにはいられませんが、実際にニーズを満たす方法を尋ねることなく、これを実装する方法だけを尋ねたいと思います。このような状況では、ニーズは満たされませんが、要求は満たされることがよくあります。

たとえば、1 つのサーバーへの 1000 のリクエストとローテーションについて心配する代わりに、単純な複数の IP アドレスから DNS ホスト名への構成により、ラウンドロビン方式でリクエストを分散できます。

データベースに対してセッションを調整することもできます。データベースは、読み取りの一貫性を備えた適切なストレージ機能を提供します。適切な構成があれば、「次の番号」は処理ノードによって簡単に読み取ることができます。

最後に、分散コンピューティングを活用する他の手段があります。たとえば、すべての処理ノードが新しい「次の」番号を持つことを保証するために、Paxos のようなプロトコルを開始する内部要求リレーによって要求を処理できます。

これらのテクニックはすべて簡単です。ただし、それらは単純すぎるとは思えないため、すぐにそれらを却下します。おそらく、もっと単純な代替手段を探しているかもしれませんが、それで問題はありません。ただし、2 台以上のコンピューターで、一貫して確実に、同時に、ある項目に同意させることは、私たちが望んでいるよりも少しトリッキーです。この分野で新しい取り組みを始めるのは自由ですが、余分なオーバーヘッドと複雑さには本当の理由があることに気付くだけかもしれません。これは些細な問題ではありません。

- - アップデート - -

ラウンド ロビン スタイルでリクエストを処理でき、サーバー間でリクエストを並べ替える必要がなく、N 個のサーバーしかないことがわかっている場合は、N 個の異なるリクエスト カウンターを実装できます。

  • サーバー 1 は N だけインクリメントします。count % N == 0
  • サーバー 2 は、次のことを保証して N ずつインクリメントします。count % N == 1
  • ...
  • サーバー N-1 は、次のことを保証して N ずつインクリメントします。count % N = N-2
  • サーバー N は N ずつインクリメントし、次のことを保証します。count % N = N-1

もちろん、クロスサーバー カウントは、短いセッションではグローバルな順序から外れている可能性がありますが、必要なものがすぐに得られる可能性があります。

  • リクエストごとの一意のカウント
  • サーバーごとのリクエストの順序付け
  • すべてのサーバーで一意であることが保証されたカウント
  • どのサーバーがリクエストを処理したかを判断する簡単な方法

あなたに欠けているもの

  • サーバー間でのリクエストの正しい順序付け
于 2013-10-04T13:29:56.243 に答える
0

以下は、セットアップに必要な最小の労力から最大の労力まで、注文したすべての選択肢です。

  1. memcached-session-managerさまざまな Tomcat にわたってセッションを保存するために使用します
  2. sqliteテーブル/コレクションにカウンターを格納するような軽量データベースを使用する
  3. 共有ファイル システムを使用し、カウンターをテキスト ファイルに格納する
  4. Redis、Memcahed、Ehcache、Hazelcast などの軽量キャッシング プロバイダーを使用する
  5. JMS などの Messaging を使用し、カウンターを渡し続ける
于 2013-10-04T13:50:52.667 に答える