20

おそらく同じ物理マシン上に存在する JVM 間のマスター/スレーブ通信を必要とする Java アプリケーションを作成しています。Java EE アプリケーション サーバー (つまり JBoss) 内で実行される「マスター」サーバーがあり、「スレーブ」クライアントが接続し、通信のために自身を動的に登録します (つまり、マスターはサーバーの IP アドレス/ポートを認識しません)。そのため、事前に設定することはできません)。マスターサーバーは、スレーブにワークアウトするコントローラーとして機能し、スレーブは定期的に通知で応答するため、双方向通信が行われます。

私は当初、各サイドがサーバーになる RPC ベースのシステムを考えていましたが、複雑になる可能性があるため、開いているソケットがあり、やり取りするメカニズムを好みます。

メッセージがほとんどプリミティブ型である低レイテンシの通信メカニズムを探しているので、重大なシリアライゼーションは必要ありません。これが私が見たものです：

  • RMI
  • JMS: Java に組み込まれている「スレーブ」クライアントは、アプリケーション サーバー内の既存の ConnectionFactory に接続します。
  • JAX-WS/RS: マスターとスレーブの両方が、双方向通信用の RPC インターフェースを公開するサーバーになります。
  • JGroups/Hazelcast: 共有分散データ構造を使用して通信を促進します。
  • Memcached/MongoDB: これらを「キュー」として使用して通信を容易にしますが、クライアントはポーリングする必要があるため、遅延が発生します。
  • Thrift: これは永続的な接続を維持しているように見えますが、Thrift サーバーを JBoss に統合/埋め込む方法がわかりません
  • WebSocket/Raw Socket: これは機能しますが、必要以上に多くのカスタム コードが必要です。

欠けている技術はありますか？

編集：また見た：

  • JMX: クライアントを JBoss の JMX サーバーに接続し、双方向通信の JMX 通知を受信します。
4

11 に答える 11

5

Java ベースのものを探しているなら、JMS をお勧めします。探しているすべての機能に加えて、JBoss などの強力なアプリケーション サーバーを備えています。ただし、完全に Java ベースではなく、キューを使用しない別のオプションは、HTTP プロトコルと JAXB (RESTful Web サービス) を使用することです。これは、2 つの側の間で通信するための非常に軽い方法です。オブジェクトは JAXB を使用して XML に変換され、反対側に転送され、受け取ったらオブジェクトにキャストし直します。

于 2010-04-08T22:00:33.000 に答える
4

正直なところ、私は JMS に固執します。スレーブがメッセージを取り出すことができる 1 つのキューと、メッセージを戻すキューが 1 つあります。誰が各メッセージを (アカウンティングのために) 処理したかに関するプロパティをエンベロープで設定できます。多くの J2EE プロバイダー (glassfish、jboss) との永続性が得られます。

さらに、追加のプログラミングなしで、複数サーバーの分散 JVM に簡単に移行できます。

ただし、場合によっては「低遅延」の定義に当てはまらない場合があります。

于 2010-04-07T19:27:23.880 に答える
3

さらに 2 つのオプション:

Zookeeper ( http://hadoop.apache.org/zookeeper/ ) 使用していませんが、適切に聞こえます。RabbitMQ ( http://www.rabbitmq.com/ ) 低遅延のメッセージ キューイング。ここには多くの柔軟性があります。

于 2010-04-07T19:21:54.783 に答える
3

パフォーマンスを求めていて、両方のアプリケーションが Java で、その間にファイアウォールがない場合は、すべての XML ベースのプロトコルをすぐに除外できます。通信が同期の場合 (マスターはスレーブがジョブを完了するのを待つ)、RMI を使用し、それ以外の場合は JMS を使用します。パフォーマンスを最大化するために、TCP を直接使用することもできます。同じメッセージを受信するスレーブが多数ある場合は、JGroups や Spread (より高速ですが、100% Java ではありません) などのグループ通信ツールキットを調べることができます。最終的に、あなたが構築しようとしているものが他の人によって既に構築されていることに気付くかもしれません。グリッドゲインを見てください。

于 2011-05-27T09:52:05.053 に答える
1

Mule も確認できます。あなたの問題の完璧な解決策だと思います。

于 2011-05-25T12:12:21.893 に答える
0

Activatableをご覧になることをお勧めします。作業が完了したときにスレーブが応答している場合は、この場合、rmiとActivatableが適切なソリューションになる可能性があります。コントローラでrmiregistryを使用すると、すべてのスレーブがコントローラに簡単に登録でき、必要に応じてこれらをアクティブ化できます。

于 2010-04-07T18:33:09.627 に答える
0

Thrift の場合、Thrift サービスのエントリ ポイントとして TServlet を使用できます。あなたが説明したことは、activemqまたはzookeeperで解決される問題のように聞こえます。

于 2011-10-28T18:55:09.590 に答える
0

同様のアプリケーションがあり、JBoss でサーブレットを使用し、「スレーブ」がタイマー駆動の方法でヒットしました。これは問題ありませんが、低レイテンシには最適ではありません。

現在、Netty を調査中です。使用したい任意のプロトコルを使用できます。おそらく、HTTP と JAXB を使用します。これは「WebSocket/Raw Socket」に分類できると思いますが、生のソケットを使用するよりもはるかに優れています..

于 2010-04-07T18:23:50.053 に答える
0

You can also take a look at Redisson project it has publish/subscribe and other shared distributed data structures for you needs.

于 2016-02-12T14:15:18.533 に答える
0

WebSocket は、2 つの JVM 間ではなく、Web サーバーとクライアント間の通信に役立ちます。それが実際に必要な場合は、http://fermiframework.orgが Java から JavaScript (サーバーからクライアント) への RMI を提供しています。

于 2014-03-25T20:18:21.803 に答える
0

要件によっては、Raw Socketのコードが他のアプローチよりも少ないことがわかる場合があります。それは確かに最低のレイテンシーを持っています. ループバックで約 20 マイクロ秒まで短縮できます。

要件が多ければ多いほど、高レベルのソリューションが必要になる可能性が高くなります。ただし、軽量なものだけが必要な場合は、生のソケットが最も単純な場合があります。

于 2011-05-30T17:51:03.603 に答える