0

複数の通信プロセスを持つシステムを作りたい。

マスター プロセスがイベントを発生させます。それぞれが構造化データを含むさまざまなイベントがあります。いくつかのスレーブ プロセスがイベントをサブスクライブし、データを受信して​​、適切なハンドラーを呼び出します。私のケースについては、2 つの考慮事項があります。

  1. サードパーティのサービスがないため、セキュリティについて心配する必要はありません。
  2. パフォーマンスが気になります。

この状況では、Zero MQ のようなメッセージ キューを使用することをお勧めします。私はそれがどのように実装されるべきか少し混乱しています。私が理解している限り、ZeroMQ は生の文字列データのみを送受信できます。

パブリッシャー側でデータを文字列 (json や xml など) にパックし、サブスクライバー側でデータを手動でアンパックして、必要なメッセージのみをフィルタリングする必要がありますか?

私の問題にアプローチするより良い方法があれば、それを聞いてとてもうれしいです.

4

2 に答える 2

0

説明したシナリオでは、メッセージングプロバイダーを使用します。私が見る利点は

1）サブスクライバーにメッセージを配信するためのコードを記述する必要はありません。それでは、ビジネスロジックとデータ形式に集中しましょう。データ形式（XML / JSON /要件に適合し、サブスクライバーが理解できる任意の形式）を決定し、メッセージを公開できます。

2）要件が発生した場合、コードを追加/変更せずにサブスクライバーの数を増やすことができます。

3）サブスクライバーは、ソリューションに影響を与えることなく、別のマシンに移動できます。

4）サブスクライバーはオフラインにすることもでき、マスター/パブリッシャーは引き続きメッセージを公開できます。サブスクライバーは後で参加して、必要なハンドラーを呼び出すことができます。

于 2013-03-07T03:30:52.393 に答える
0

これらは私が見るオプションです：

  1. イベントの耐久性と永続性が要件の一部ではなく、パフォーマンスのみが懸念される場合は、カスタム定義のプロトコル構造でデータをバイト配列にパックし、プロセス間通信にソケットを使用します。ただし、注意してください-カスタムバイト配列構造は、拡張性と保守性の点でコストがかかります。他のオプションは、比較的読みやすいデータ交換形式としてJSONを選択することです。
  2. イベントデータの耐久性と永続性が要件の一部である場合は、メッセージ指向ミドルウェアの利点を利用してください。宣言型同期などの機能は、MOMがもたらすことができる他の利点の一部です。
于 2013-03-07T11:42:58.240 に答える