ユーザーがキューからメッセージを再生できるようにする再生メカニズムを設計しようとしています。複数のキューと複数のコンシューマーを含む取引所に対して私が思いついた最良の設計は次のとおりです。
次のようなレコーダー サービスを作成します。
- キューを作成し、すべてのルーティング キーをそれにバインドします。
- 交換からのすべてのメッセージを消費します。
- すべてのメッセージを DB に保存します。
サブスクライバーのリプレイ要求。
- 各サブスクライバーは、新しいエクスチェンジ、キューを作成し、通常のキューと同じバインディングでそれにバインドします。
- サブスクライバーは、フィルター (開始日など) を使用してリプレイを開始するために、残りの要求を Web サーバーに送信します。リクエストには、そのリプレイ交換名が含まれています。
- Web サーバーは DB からデータを取得し、特定の取引所に公開します
- RequestId を添付してエコーバックするなどの改良を加えることができます。
質問:
1. それは理にかなっていますか?
2.私は車輪を発明していますか? うさぎ固有の解決策はありますか？プラグイン？
3. 複数の取引所を作成することは良い習慣と考えられますか?
このソリューションでは、同じメッセージを発行するために、各キューの交換が作成されます。
別の解決策:
1. キューごとに追加のキュー「ReplayQueue」を作成します。TTL を設定します (1 か月としましょう)。
2. ユーザーがリプレイを要求するたびに、応答せずに独自の ReplayQueue からリプレイできるようにします。
このソリューションは少し問題があります。
- 最終日を再生するには、消費者はそれ以前の 29 日間をすべて取得して、それらを除外する必要があります。
- このソリューションはスケールアップします - キューは大きくなります (スケールアウトできる db ストレージとは異なります)。