8

現在、IT 部門がハードウェアを購入済みのアプリケーションを作成しています。彼らのアプローチは、私たちが展開する大きなハードウェアを購入することでした。さらに処理を追加するために、同じソフトウェアを搭載したサーバーを追加することを計画しています。この設計に対応するために、Terracotta を使用して、複数の JVM を 1 つの大きな JVM であるかのように実行できるようにしています。これが賢明な方法であるかどうかに関係なく (私はまだ確信が持てません)、これが私が対処している状況です。

いずれにせよ、標準のプロデューサー/コンシューマー タイプのキューを使用するアプリケーションの一部があります。Terracotta を使用すると、複数の JVM で動作する単一のキューを作成できます。これはかなり滑らかで、うまく機能します。

しかし現在、非同期プロセスを実行する機会が増えています。すべてのキューイング ロジックの一貫性を高めるために、JMS を使用して共通のロジックを抽象化することを検討しています。JMS をリモート キューとして使用する予定はないため (少なくとも当面は)、JMS が不必要な複雑さを追加しているだけなのではないかと考えています。

提案や考えはありますか？キューを並行構造として構築し続けるか、それとも別個の潜在的にリモートなオブジェクトとして扱うべきでしょうか?

4

3 に答える 3

6

メッセージ キューは基本的には、いくつかの凝ったオプションを持つ Queue データ構造です。プロジェクトが他のほとんどのプロジェクトと同様である場合、特に Terracotta が永続性と分散を処理しているため、JMS を古いQueue実装とは異なるものにする JMS 機能を使用していません。

したがって、JMS はおそらくアプリケーションに複雑さを加えているだけであり、これは JMS が得意とするところです。複雑さのすべての不要な要因と同様に、それを取り除きます。1 つ以上の理由で JMS を使用することに決めた場合は、それを実行してください。

于 2009-08-11T06:36:38.557 に答える
1

Terracotta は使用していませんが、Terracotta に非常によく似た分散キャッシュ製品を使用しています。私たちのアーキテクチャも、あなたが持っているものと似ているように聞こえます。プロデューサとコンシューマの両方が同じキャッシュにあり、キャッシュ サブシステムを使用してデータを共有します。

JMS を追加することは不必要に複雑になる可能性があるという原則には同意しますが、分散キャッシュは巧妙ではありますが、メッセージング メカニズムの最適な実装ではないことがわかりました。同じセマティクスを作成できますが、いくつかの細かい点が問題を引き起こします (コンシューマーの負荷分散など、分散キャッシュとの追加の同期化が必要になる場合がありますが、JMS では自然に機能します)。

将来のユースケースで永続性などを備えたより多くの pub-sub セマンティクスが必要になると思われる場合は、JMS について考え始めることをお勧めします。また、関心の分離を検討してください。Terracotta を使用してデータを配布しています (これが目的です)。また、それを使用して制御命令を配布しますか?

于 2009-08-11T15:51:20.310 に答える
1

私の同僚はMuleを使用しています。これにより、JVM 内または JVM 間のキューであるキューを定義できます。

私はkrosenwaldに同意します.Terracottaから離れる（または少なくともオプションがある）という一般的な計画がない限り、JMSがあなたの場合に何を追加するかは明確ではありません.

于 2009-08-11T06:50:15.347 に答える