イベントドリブン公開サブスクリプションモデル

Question

プロセス（つまりプロデューサ）が可変数のプロセス（つまりコンシューマ）に一方向のメッセージを送信する必要があるという要件に取り組んでいます。

パブリッシュ・サブスクライブ・モデルは、コンシューマがプロデューサからのメッセージをサブスクライブするため、このように見えました。私はこれを達成するためにZeroMQを使ってみました。

1. 消費者が継続的にメッセージをポーリングする必要があります。

   はしかし、私はそれでいくつかの問題を抱えています。私は新しいメッセージがあるときに通知を受ける消費者を持っています。

2. プロデューサキューがいっぱいになる可能性があります。私は、プロデューサーが何らかの条件（5秒より古いメッセージを削除する、または5回読み込まれたメッセージを削除するなど）に基づいてキューからメッセージを削除することが好きだったでしょう。

3. コンシューマがポーリングしているため、メッセージはキューから削除されないため、コンシューマは新しいメッセージが到着するまで重複メッセージを表示します。

私は間違ったモデルを使用している可能性があることを理解しています（公開購読は適切ではないかもしれません）。私はrequest-replyを使うことを考えましたが、プロデューサーは消費者の数を把握したくないので動作しません。

誰かが良い選択肢を提案できますか？

Answer 1

複数のプロデューサーが必要ですか？そうでなければ、PUB/SUBの代わりにPUSH/PULLを使用できます。

プッシュ/プルでは、​​必要な数のコンシューマを使用できます（モデルのPULL側です）。 PUSHエンドポイントに書き込まれたすべてのメッセージは、接続されたすべてのコンシューマ間でラウンドロビン方式で分散されます。これにより、2人の消費者が同じメッセージを受信しないことが保証されます。

説明したように、コンシューマをSUBエンドポイントとして使用すると、2つ以上のコンシューマが同じ "プレフィックス"を購読している場合、複数のコンシューマに同じメッセージを配信することができます" 「接頭辞」と仮定すると、

を使用すると、JMSプロバイダまたはAMQPプロバイダを使用してみてくださいsock.setsockopt(ZMQ_SUBSCRIBE, "prefix", ...);

Answer 2

に渡す文字列です。これらはトピックで探しているものがいくつかあります：

1. プッシュ通知を購読者に送信します。

2. メッセージがTTL内で消費されない場合、メッセージを削除またはデッド・レター・キューに入れることを可能にするメッセージの存続可能時間属性。

3. 一度限りの通知 - 設定に応じて

一度だけのメッセージングが失われたメッセージや重複メッセージのいずれかが発生することができますネットワークfailuerのイベントでエッジの条件を持っているん...あなたが選びます。

この点で、使用することができます。 RabbitMQはAMQPで人気があります。 JMSには、独自の製品やオープンソースの実装がいくつでもあります。

Answer 3

私は、プロデューサとコンシューマの間でブローカを使用したプッシュプルモデルに進むことをお勧めします。

1. 新しいメッセージについては、ブローカに通知する必要があります。
2. お客様はブローカーに通知を待ちます（成功/失敗を追跡するためにテーブルを保持します）。
3. ＃2が完了すると、コンシューマーはProducer（ソース）からデータを取得し、ack成功/失敗のために仲介する

希望これは

Answer 4

DDS（データ配信サービス）ミドルウェアはあなたがはるかに簡単に達成しようとしている正確に何をサポートするのに役立ちます。

が直接あなたの質問に答える：

1. DDSは、リスナーのメカニズムをサポートし、あなたの加入者が継続的にポーリングする必要はありません。

2. DDSには、パブリッシャキューがいっぱいになるのを防ぐためのQoS設定があります。履歴QoSを使用して、「キューに最新の10個のサンプルだけを残す」と言ったり、ライフスパンQoSを使用して「過去10秒間に公開されたサンプルのみを保持する」と言うことができます。

3. また、DDSリスナーメカニズムを使用することができます。新しいサンプルごとに1回だけ通知されます。ポーリングする必要はありません。

オープンソースの実装は現在2つあります。

• OpenSplice：https://github.com/OpenSplice/opensplice
• OpenDDS http://www.opendds.org/