web-dev-qa-db-ja.com

Rabbitmq-メッセージ再生サービスの設計

ユーザーがキューからメッセージを再生できるようにする再生メカニズムを設計しようとしています。複数のキューと複数のコンシューマーを含むエクスチェンジについて私が思いついた最良の設計は次のとおりです。

  1. 次のようなレコーダーサービスを作成します。

    • キューを作成し、すべてのルーティングキーをそれにバインドします。
    • 取引所からのすべてのメッセージを消費します。
    • すべてのメッセージをDBに保存します。

  2. サブスクライバーによる再生の要求。

    • 各サブスクライバーは、新しい交換キューを作成し、通常のキューと同じバインディングでそれにバインドします。
    • サブスクライバーは、フィルター（開始日など）を使用して再生を開始するために、残りの要求をWebサーバーに送信します。リクエストには、リプレイ交換名が含まれています。
    • WebサーバーはDBからデータを取得し、それを特定の取引所に公開します
    • requestIdを添付してエコーバックするなど、改良を加えることができます。

enter image description here

質問：
1。それは理にかなっていますか？
2。私は車輪の再発明をしていますか？ウサギ固有の解決策はありますか？プラグイン？
3。複数の交換を作成することは良い習慣と見なされますか？
このソリューションでは、同じメッセージを公開するために、各キューの交換が作成されます。

別の解決策：
1。キューごとに追加のキュー「ReplayQueue」を作成します。 TTL（1か月としましょう）を設定します。
2。ユーザーがリプレイをリクエストするたびに、ユーザーは自分のReplayQueueから確認せずにリプレイできます。

この解決策は少し問題があります。

  • 昨日再生するには、消費者は29日前のすべてを取得し、それらを除外する必要があります。
  • このソリューションはスケールアップします-キューは大きくなります（スケールアウトできるデータベースストレージとは異なります）。
rabbitmqmessage-queuereplay
23
Bick
  1. それは理にかなっていますか？

はい

  1. 私は車輪の再発明をしていますか？ウサギ固有の解決策はありますか？プラグイン？

あなたは車輪の再発明をしているのではありません。 AFAIKには、ウサギのソリューションやすぐに使えるソリューションはありません。

あなたの最初の解決策は私の意見では良いです。 Another solutionは非常に問題があります。なぜなら、健康なウサギは空のウサギであり、ウサギはデータストアではないからです。

公開されたすべてのメッセージをルーティングするキュー（STORE）があります。 STOREをすべてのバインドキーでバインドする代わりに、トピック交換の使用を検討できます。その代償として、バインディングキーには. # *が含まれていてはならず、メッセージがルーティングされるときにわずかなオーバーヘッドが発生します。 STOREキューは、バインディングキー#でバインドされます。

firehose をご覧ください。

なぜWebリクエストなのですか？ RPC呼び出し でRabbitを使用できます：

  • サブスクライバーは、フィルター（開始日など）を使用して再生を開始するためのamqp要求を送信します。
  • リクエストにはreply-toキュー名が含まれています。キューは、クライアントとリクエスト専用の場合があります。
  • RPCサーバーはDBからデータをプルし、それを返信先キューに公開します

direct-reply-to パターンも確認できます。

  1. 複数の交換を作成することは良い習慣と見なされますか？

はい、必要に応じてすぐに。あなたの特定のケースでは、私の意見では、加入者ごとの交換は必要ありません。リクエストにはすでにキュー名が含まれています。デフォルトの交換amq.directを使用し、ルーティングキーをキュー名と同じにするだけで、このキューに公開できます。エクスチェンジが必要な場合は、一意のエクスチェンジ（「リプレイ」など）を作成し、各サブスクライバーにリプレイキューをこのエクスチェンジにバインドさせます。 「リプレイ」交換は、慣例である場合もあれば、リクエストとともに送信される場合もあります。

7
Nicolas Labrot

最初の解決策は実行可能です。ウサギMQにはtracing pluginが付属しているため、メッセージをDBに保存するのは、amq.rabbitmq.trace交換にバインドされたキューから消費するだけなのでさらに簡単になります。

この交換はvhostに固有であり、すべての仮想ホストには独自のamq.rabbitmq.trace交換があります。さらに、新しいトレースを作成するときに、トレースを有効にするキュー/交換を制限することができます。これにより、トレースが不要な場合にトレースを無効にする柔軟性が得られます。

トレースを構成するには、次のリンクを参照してください。
https://www.rabbitmq.com/firehose.html
https://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/

2
Simrandeep Singh