問題タブ [bunny]

RabbitMQ の Bunny gem を Rails に統合しています。Rails がアプリケーションの開始時に開始するイニシャライザーで Bunny スレッドを開始するか、別の rake タスクで開始して、別のプロセスで開始できるようにする必要がありますか?

メッセージのみを生成している場合は、アプリ全体で使用できるように Rails 初期化子で行う必要があると思いますが、消費している場合は別の rake タスクで行う必要がありますが、これは正しいですか?

いくつかのワークフローのユースケースについて、RabbitMQ をチェックしています。

これまでのところ、Ruby を使用して、ニーズに合ったテスト環境を作成し、問題なく動作しているようです。

うさぎの初心者の場合、私が持っている質問は、ベスト/グッドプラクティスについてです.

3 つの QUEUES を定義しましょう (例として)

1. Q_決定
2. Q_RIGHT
3. Q_LEFT

すべてのプロデューサーは Q_DECISION 内にメッセージを投稿します

そのキューで実行されているワーカーがあり、本文の一部のコンテンツをチェックします。決定の場合、メッセージ/タスクを Q_LEFT または Q_RIGHT に移動する必要があります。

メッセージ固有の情報 properties.headers を格納しているため、本文と同様に繰り返します。

これまでのところ問題ありません。質問は再公開に関するものです。

上記のように再発行すると、以前のメッセージから何かが失われますか?

と には多くの属性が定義/保存されdelivery_infoてpropertiesいます。

それらを再投稿する必要がありますか、それとも自己作成のヘッダーと本文のみですか?

Rabbitでワークフロー環境をセットアップしました。

それは私たちのニーズを解決しますが、スケジュールされたタスクのようにそれを行うことも良い習慣であるかどうかを知りたい.

スケジューリングとは、ミッション クリティカルな 100% 調整された時間がないことを意味します。したがって、ジョブを 60 秒後に再試行する必要がある場合は、60 秒以上かかることを意味し、キューがいつ処理されるかによって異なります。

Q_WAIT を 1 つ作成し、設定を転送するためのヘッダーをいくつか作成しました。

次のようにしましょう:

ワーカーは Q_ACTION でサブスクライブされて実行されています

アクションが失敗した場合 (smtp サーバーに到達できないなど)

-> (再) メッセージを Q_WAIT にパブリッシュし、properties.headers["scheduled"] = time + 60seconds を設定します。

別のプロセスは、メソッド pop() によって Q_WAIT 内のすべてのメッセージを 15 秒ごとにループし、subsubscribed によってループしません。

各ループの後、接続が閉じられ、NOT (Re-)Published が確認されなかったために Q_WAIT に残されます。

誰かがこれを実用的な（良い）慣行として確認できますか。

これが可能かどうか疑問に思っていました。キューからタスクをプルし、作業が完了したことを通知する ack が RabbitMQ に送り返されるまでに 3 秒以上 (場合によっては) 数分かかる可能性のある作業を行いたいと考えています。作業はユーザーによって行われるため、ジョブの処理にかかる時間はさまざまです。

確認応答が受信されない場合にメッセージを再度キューに入れたいため、キューからポップした直後にメッセージを確認したくありません。私の問題を解決する方法について誰かが私に洞察を与えることができますか?

サービス指向アーキテクチャのメッセージ キューとして RabbitMQ を使用しています。多くの個別の Web サービスが RabbitMQ キューにバインドされたメッセージを発行します。これらのキューは、バックグラウンド作業を実行するさまざまなコンシューマーによってサブスクライブされます。RabbitMQ の非常にバニラなユースケースです。

ここで、いくつかのキュー パラメータを変更したいと考えています (具体的には、特定のルーティング キーを使用してキューを新しいデッド レター交換にバインドしたいと考えています)。私の問題は、実稼働システムでこの変更を行うことが、いくつかの理由で問題があることです。

本番システムでメッセージを失わずにこれらの新しいキューに移行するための最良の方法は何ですか?

キュー名のバージョン管理から、新しい設定で新しい仮想ホストを作成すること、すべての変更を適切に行うことまで、すべてを検討しました。

ここに私が直面している問題のいくつかがあります：

1. RabbitMQ キューは冪等であるため、異種の Web サービスは、公開する前にキューを宣言しています (キューがまだ存在しない場合)。キューのパラメーターを変更すると (ただし、同じルーティング キーを維持する)、キューの宣言は失敗し、RabbitMQ はチャネルを閉じます。

2. キューを変更するときにメッセージを失わないようにしたいです (ここでは、メッセージを保存してから新しいキューに再発行する排他的なコンシューマーをサブスクライブすることを計画しています)。

3. 異なるパブリッシャーと消費者ベースの間の一般的な調整 (または、さらに良いことに、それらを調整する必要を回避する方法)。

バニーで遊んでいて、メッセージを既存のキューに発行しようとしています。残念ながら、Bunny の内部ドキュメントは、コンシューマの作成には有効ですが、produser には有効ではありません。たとえば、ある取引所にバインドしようとすると、エラーがスローされます

コード：

なぜ再宣言しようとしているのか知っていますか。

たぶん、最初にキューにバインドする必要がありますか?

助けてくれてありがとう。