7

現在、私たちはプロジェクトに取り組んでおり、プロジェクトの主なポイントは次のとおりです。

  • リアルタイムデータを生成しているスイッチがあります
  • Java/Java EE で作成する 2 つのコンポーネントがあり、それを CompA と CompB と呼びます。
  • CompA は、スイッチからの入力レコードに基づいて、どのデータベースにもアクセスせずに何らかのプロセスを適用します。CompA には DB アクセスがありません。
  • CompB は CompA のプロセス記録を取得し、処理も適用します。これにはビジネス データベースが含まれます。
  • CompA と CompB は、スケーラビリティとフォールト トレランスのためにシステム内に複数のインスタンスを持ちます。
  • レコードは、複数のフィールドを持つテキスト レコードです
  • レコードはトランザクションです。レコードが CompA と CompB の両方から処理されている場合は、処理済みと見なされます。それ以外の場合は、ロールバックされて再送信されます

ここでの問題は、CompA と Comp B の間の通信に最適な方法は何かということです

一つの方法は

1. CompA--------> CompB
 2. CompA-------->Messaging Server(JMS)------> CompB

要件:複数の CompA が存在し、CompB はシステムであり、コンポーネントに障害が発生した場合、その負荷は他のピアによって共有されます。たとえば、CompA に障害が発生した場合、その負荷はシステム内の他の CompA インスタンスによって共有されます。そのために、CompA が CompB と密接に結び付けられないように、JMS の 2 番目のオプションを使用します。しかし、新しいコンポーネント (Messaging Server) が導入されると、レコード処理がトランザクションに対応し、システムがリアルタイムであるため、パフォーマンスが低下する可能性があります。
あなたの提案と専門家のアドバイスは非常に高く評価されます

4

2 に答える 2

5

JMSは行くべき道です - http://docs.oracle.com/javaee/6/tutorial/doc/bnceh.html

非常に信頼性が高く、メッセージの有効期限を設定したり、優先度を適用したりできます。基本的にネットワーク上の「複数のプロデューサー/複数のコンシューマー」であるモデルに最適です。

JMS はトランザクションをサポートし、信頼性を重視して構築されています。利用可能なメカニズムの中で群を抜いて信頼性が高いメカニズムです。パフォーマンスに関しては、「生のパフォーマンス」よりも「スケーラビリティ」について話す必要があります。ハードウェアが対応できれば、JMS が対応します。

ウィキペディアには、利用可能な JMS 実装の非常に優れたリストがあります: http://en.wikipedia.org/wiki/Java_Message_Service#Provider_implementations

私は Apache ActiveMQ、Open Message Queue、および OpenJMS を使用してきました。クラスター環境に JMS サーバーをデプロイした経験はありませんが、ActiveMQ が私が使用した最も信頼できるソリューションであることに同意します。

于 2012-11-05T11:46:19.633 に答える
1

Spring Integration で JMSを使用することをお勧めします。 確認例

私の場合、Spring 統合で ActiveMq を使用したため、ロードバランシングを処理し、Feture を簡単にフェイルオーバーできました。

于 2012-11-05T12:02:38.713 に答える