4

これでリクエストとリプライができるのだろうか：

  • 1 つの hazelcast インスタンス/メンバー (中心点)
  • hazelcast-client がキューを介してリクエストを送信する 1 つのアプリケーション
  • キューへのリクエストを待機している hazelcast-client を持つ 1 つのアプリケーション

最初のアプリケーションは、2 番目のアプリケーションによってポストされた別のキューでも応答を受信します。

続行するのは良い方法ですか？または、より良い解決策を考えていますか？

ありがとう！

4

5 に答える 5

3

ここ数日、私は hazelcast キューを使用して異なるマシン上の異なるプロセス間で通信する「soa のような」ソリューションにも取り組みました。

私の主な目標は

  1. 1 対 1 の多の保証された応答による「1 対 1 の」通信

  2. 「1 対 1」の一方通行のコミュニケーション

  3. 一定時間内に応答する「1対1」のコミュニケーション

簡単に言うと、次の理由により、今日このアプローチをやめました。

  1. エグゼキュータ サービス、callable、runnable、InterruptedException、シャットダウン処理、hazelcast トランザクションなどを含む複雑なコードが多数

  2. 受信側の寿命が送信側よりも短い場合の「1 対 1」通信の場合のメッセージのぶら下がり

  3. 適切なタイミングで特定のクラスター メンバーを強制終了するとメッセージが失われる

  4. メッセージはどこにでも格納できるため、すべてのクラスタ メンバーがメッセージをデシリアライズできる必要があります。したがって、メッセージは特定のクライアントやサービスに「固有」であってはなりません。

私ははるかに単純なアプローチに切り替えました：

  1. すべての「サービス」は、hazelcast クラスター メンバーの UUID をキーとして使用して、MultiMap (「サービス レジストリ」) に自身を登録します。各エントリには、サービス識別子、負荷係数、開始時刻、ホスト、pid などのメタ情報が含まれています。

  2. クライアントは、その MultiMap 内のエントリの 1 つの UUID を選択し、選択した特定のクラスター メンバーに対して DistributedTask (分散エグゼキューター サービス) を使用してサービスを呼び出し、オプションで (時間内に) 応答を取得します。

  3. サービスクライアントとサービスのみがクラスパスに特定の DistributedTask 実装を持っている必要があり、他のすべてのクラスターメンバーは気にしません

  4. クライアントは、サービス レジストリ自体のデッド エントリを簡単に見つけることができます。特定の UUID (hazelcastInstance.getCluster().getMembers()) を持つクラスター メンバーが表示されない場合、サービスはおそらく予期せずに停止します。その後、クライアントは「生きている」エントリ、負荷係数が少ないエントリ、冪等のサービスの場合に再試行するエントリなどを選択できます。

2 番目のアプローチ (タイムアウトやタスクのキャンセルなど) を使用すると、プログラミングが非常に簡単かつ強力になり、維持するコードがはるかに少なくなります。

お役に立てれば！

于 2013-02-14T20:24:17.837 に答える
2

過去に、Hazelcastキューをバスとして使用するSOAシステムを構築しました。ここにいくつかの見出しがあります。

a。各サービスには収入Qがあります。単にサービス名はキューの名前です。必要な数のサービスプロバイダーを持つことができます。スケールアップとスケールダウンができます。必要なのは、これらのサービスプロバイダーがこのキューをポーリングし、到着した要求を処理することだけです。

b。システムは完全に非同期であるため、要求と応答を相互に関連付けるために、要求と応答の両方に呼び出しIDもあります。

c。各クライアントは、呼び出したいサービスのキューにリクエストを送信します。リクエストには、サービスのすべてのパラメータ、レスポンスを送信するキューの名前、および呼び出しIDが含まれています。キュー名は、単にクライアントのアドレスにすることができます。このようにして、各クライアントは独自のキューを持ちます。

d。要求を受信すると、サービスプロバイダーはそれを処理し、応答を応答キューに送信します

e。また、各クライアントは入力キューを継続的にポーリングして、送信する要求に対する回答を受け取ります。

この設計の主な欠点は、キューがマップほどスケーラブルではないことです。したがって、それはあまりスケーラブルではありません。ただし、1秒あたり5Kのリクエストを処理できます。

于 2013-02-09T00:30:58.020 に答える
2

私は自分自身でテストを行い、特定の制限でうまく機能することを検証しました.

アーキテクチャは Producer-Hazelcast_node-Consumer(s) です

リクエスト用とレスポンス用の 2 つの Hazelcast キューを使用すると、1 ミリ秒未満の往復を測定できました。

Request キューに複数のコンシューマーを配置すると、負荷分散は正常に機能します。

別のノードを追加し、クライアントを各ノードに接続すると、往復は 15 ミリ秒を超えます。これは、2 つの hazelcast ノード間のレプリケーションによるものです。ノードを強制終了しても、クライアントは引き続き動作します。したがって、フェイルオーバーは時間を犠牲にして機能します。

于 2013-02-11T15:23:12.617 に答える
1

相関 ID を使用して、hazelcast の単一のキューで要求と応答を実行できませんか? これは、キューの 2 つのプロバイダー/コンシューマー間の会話を一意に定義する ID です。

于 2013-01-21T18:25:52.950 に答える
0

このセットアップ@unludoの目的は何ですか?. ただ興味があるだけ

于 2013-02-07T05:50:35.473 に答える