問題タブ [rabbitmq]

RabbitMQ と結び付いていないErlang AMQPクライアント ライブラリはありますか?

私はrabbitmq-erlang-clientについて知っていますが、もっと分離したものが欲しいです... Debianリポジトリ、インストールなどのためにこれをパッケージ化することになると苦痛です...

Java クライアントを使用して RHEL 5.3 で RabbitMQ を使用しています。2 つのノード (マシン) があります。Node1 は、Java ヘルパー クラス QueueingConsumer を使用して、Node2 のキューからメッセージを消費しています。

ノード 1 またはノード 2 でインターフェイスがダウンした場合 (例: ifconfig eth1 down)、クライアント (上記) はネットワークが存在しないことを認識しません。RabbitMQ は、接続が切断されたかどうかを判断するために使用できる、Java クライアントで何らかのタイプの構成を提供しますか。Node2 で RabbitMQ サーバーをシャットダウンすると、ShutdownSignalException がトリガーされます。これはキャッチされる可能性があり、アプリは再接続ループに入る可能性があります。ただし、インターフェイスを停止しても、どのような種類の例外も発生しないため、コードは consumer.nextDelivery() を永遠に待機します。

また、この呼び出しのタイムアウト バージョンを使用してみました。例えば

ただし、これは常に true を返すようです (インターフェイスがダウンしていても)。接続で ShutdownListener に登録しても同じ結果が得られると思いますが、まだ試していません。

ある種のハートビートを構成する方法はありますか、それともカスタム リース ロジック (「私は今ここにいます」など) を記述して、これを機能させる必要がありますか?

自分のニーズに合ったメッセージングシステムを探しています。手伝って頂けますか ？

• 今のところ、処理するデータの量はそれほど多くありませんが、後で制限されたくありません...
• マシンは単なるWebサーバーではないため、処理速度がそれほど速くない場合でも、メッセージングツールは軽量である必要があります。
• サーバーで一部のデータが変更された場合、すべてのサーバーがその情報を保持し、ローカルで処理する必要があります。（それぞれのサーバーごとに1つのチャネルを作成する必要がありますか？）
• フロントエンドはRailsで記述されているため、開発を簡素化するために、送信される通信とデータを管理するためのgem/プラグインがあることが重要です。

現時点では ：

• RabbitMQ+worklingは私のニーズに合っているようです。これは正しい選択でしょうか？
• ActiveMQは、Javaのせいで、私を恐れさせます（Javaについてはよくわかりませんが、CPUを大量に消費しているようです）。
• 他の人は彼らほど成熟していないようです。

この種の技術を使った開発はたくさんあるかもしれないので、間違った方向に進むことはできません！

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

セロリの通常のタスクまたはPeriodicTaskを削除するにはどうすればよいですか？

C / C ++アプリでRabbitMQを使用しようとしていますが、これまでのところ、OpenAMQのCクライアントを使用することが唯一のオプションであることに気付きましたが、OpenAMQはAMQP 0-9であり、RabbitMQサーバーは0-8です。どこかで、RabbitMQをOpenAMQ C libで動作させるために小さな変更を加えることに成功したことを読んだことがあります。これを経験した人は、少し光を当てることができます。

Windows に RabbitMQ をインストールするにはどうすればよいですか?

誰かがWindowsでrabbitmqCクライアントライブラリを構築する方法に光を当てることができますか？

プロセス A は、オブジェクト a1、a2、a3 などの値を計算し、結果をミドルウェア キュー (RabbitMQ) に送信しています。コンシューマーはキューを読み取り、これらの結果をさらに処理します。プロセス A は定期的にこれらの値のスナップショットを送信する必要があるため、コンシューマーは他の計算を行うことができます。これらのオブジェクトの値は、個別に変更される場合があります。キューは次のようになります a1、a1、a2、a1、a2、a2、a3... コンシューマーはキュー内の各アイテムを処理します。スナップショットにはすべてのオブジェクトが含まれている必要があり、コンシューマーはすべてのオブジェクトについてこのメッセージを一度に処理します。

したがって、要件は次のようなキューを持つことです：a1、a1、a3、a2、a2、[スナップショット、a1、a2、a3]、a3、a1 ...問題は、これらのアイテムが異なるタイプであることです：1つのタイプスナップショットの a1、a2 などのオブジェクトの場合。これは、異なるキューで処理する必要があることを意味しますが、その場合、競合状態が発生します。コンシューマーは、スナップショットを処理する前にオブジェクトを処理する可能性があります。

この(非常に一般的な)問題を解決するパターンはありますか? メッセージのキューイングには RabbitMQ を使用しています。

私は現在、メッセージ キュー システムを評価しており、RabbitMq が良い候補のように思われるので、もう少し掘り下げています。

少しコンテキストを与えるために、複数のキューに発行するメッセージを負荷分散する 1 つの交換のようなものを探しています。メッセージを複製したくないので、ファンアウト交換はオプションではありません。

また、消費者とのラウンドロビンを処理する 1 つのキューに対して複数のキューを使用することを考えている理由は、単一障害点をキュー レベルにしたくないからです。

パブリッシャー側にロジックを追加して、ルーティング キーを編集し、適切なバインディングを配置することで、その動作をシミュレートできるように思えます。しかし、これは、各キューでのメッセージ消費のペースを考慮しない一種の受動的なアプローチであり、そのキューのコンシューマ アプリケーションが停止した場合、1 つのキューがいっぱいになる可能性があります。

私は交換エンティティ側からより積極的な方法を探していました。それは、各キュー サイズまたはその性質に基づいて次のメッセージをどこに送信するかを決定します。

Alice と利用可能な RESTful API について読んだことがありますが、これは高速なルーティング決定を実装するための非常に重要なソリューションのように思えます。

交換キュー間のラウンドロビンがRabbitMQで実現可能かどうかは誰にもわかりますか? ありがとう。

私は、RabbitMQ を使用してキューにメッセージを送信するシステムを Ruby で開発しています。私は使っている：

• Ruby 1.9.1 安定版
• ウサギMQ 1.7.2
• AMQP gem v0.6.7 ( http://github.com/tmm1/amqp )

この gem で見たほとんどの例では、EM.add_periodic_timer ブロックにパブリッシュ呼び出しがあります。これは、大多数のユースケースであると思われるものでは機能せず、確かに私のものでは機能しません。いくつかの作業を完了するときにメッセージを発行する必要があるため、発行ステートメントを add_periodic_timer ブロックに入れるだけでは不十分です。

そのため、いくつかのメッセージをキューに発行し、それを「フラッシュ」して、発行したメッセージがサブスクライバーに配信されるようにする方法を見つけようとしています。

私が言いたいことを理解してもらうために、次の発行者コードを考えてみてください。

したがって、このコードは単純にループし、ループの各反復で 40% の確率でメッセージを公開し、その後 0.1 秒間スリープします。50 件のメッセージが公開されるまでこれを行い、その後 AMQP を停止します。もちろん、これは概念実証にすぎません。

さて、私のサブスクライバーコード：

したがって、キューにサブスクライブするだけで、受信したメッセージごとに出力します。

パブリッシャーが AMQP.stop を呼び出したときに、サブスクライバーが 50 個のメッセージすべてを受信することを除けば、素晴らしいことです。

これが私の出版社からの出力です。簡潔にするために途中で切り捨てられています。

次に、サブスクライバーからの出力:

出力のタイムスタンプに注意すると、サブスクライバーは、パブリッシャーが AMQP を停止して終了した後にのみ、すべてのメッセージを受信します。

では、AMQP の初心者として、メッセージをすぐに配信するにはどうすればよいでしょうか? パブリッシャーの while ループの本文に AMQP.start と AMQP.stop を入れてみましたが、最初のメッセージしか配信されませんでしたが、奇妙なことに、ログを有効にすると、サーバーからエラー メッセージが報告されず、メッセージはキューに送信されますが、サブスクライバーによって受信されることはありません。

提案をいただければ幸いです。読んでくれてありがとう。