問題タブ [cloudamqp]

AppHarbor で MVC4 で動作する Web アプリの構築を検討しています。応答性とパフォーマンスのために、実行時間が少し長いタスク (通常、電子メールの生成/送信、画像のサイズ変更、支払いトランザクション処理など) は、メッセージをメッセージ キューに入れることで処理されます。

また、メッセージをデキューし、結果として処理する必要があるものを処理する 1 つまたは複数のワーカーがどこかに存在します。中央のキューイング メカニズムは、RabbitMQ、具体的には AppHarbor を介して利用できるホストされた CloudAMQP サービスです。理論的には、このアーキテクチャではワーカーを追加することで「無限」のスケーラビリティが可能になります。

ここで、優れたアーキテクチャ、テスト容易性などのために、簡単にモックできる 1 つ以上のインターフェイスの背後に RabbitMQ を配置したいと考えています。これらのインターフェースを定義する際に考慮すべき点がいくつかあります。

• 有料ユーザーを獲得するまでは、無料の CloudAMQP オファリングに限定されます。これは、最大 3 つの同時接続を意味します。
• 前の制約を考慮して、アプリケーションごとに 1 つの接続に制限しようと思います。MVC アプリ用に 1 つ、ワーカーごとに 1 つ。それでおしまい。
• RabbitMQ の接続は、長期間存続するように設計されています。それでも、多くの例では、接続 (次にチャネル) を明示的に開き、メッセージを送信してから再び閉じるコードを示しています。
• マルチスレッドの場合、同じ接続を使用できますが、同じチャネルは使用できません。私が理解している限りでは、マルチスレッド アプリで接続を共有してから、複数のチャネル (たとえば、スレッドごとに 1 つ) を開くことは問題ありません。
• 通常、私の MVC アプリはパブリッシャーのみです。ワーカー アプリはコンシューマーとパブリッシャーの両方になります。たとえば、ワーカーは支払いを処理するメッセージを受信できます。その結果、成功または失敗を示す電子メール メッセージをユーザーに呼び出すメッセージを発行します。
• MVC アプリの場合、接続は通常、非常に短い時間 (メッセージをキューに入れるため) だけ使用されます。
• ワーカーについては、ワーカーの存続期間中、多かれ少なかれ永続的に開いている長期接続を考えています。

わかりました、それでたくさんのものがあります。このプロジェクトの前に RabbitMQ の経験がなかったので、いくつかの追加の箇条書きに悩まされています。

• インターフェイス分離の原則。これを IQueueServiceConsumer と IQueueServiceProducer のような 2 つの別個のインターフェイスに分割する必要がありますか? 私はいつでも SRP などを使用して物事をさらにアトミックな単位に分割できることがわかりました。また、ボブおじさんに (インターフェース名の I よりも多くのことで) 私を追い詰められたくありませんが、どこまでやるべきか疑問に思っています。これを取る。
• 少なくとも最初は Web サーバーを 1 つしか持たないことを考えると、実際に Web アプリのキューへの接続を長続きさせることは考えられるでしょうか? それらを開いたり閉じたりすると、論理的には複数が同時に発生する可能性があり、競合や潜在的なメッセージが失われる可能性があります。メッセージの紛失は認められません。
• この場合、接続の存続期間をどのように処理しますか? 私のNinjectモジュール（私のインターフェースが実際にRabbitMQ固有の実装にバインドされている場所）内でそれを開き、アプリケーションが...リサイクルされたときに何らかの方法で切断しますか? どうすればそのようなことができますか？
• 労働者にとって、生活は楽に思えます。インターフェイスにメソッドを配置して接続を開き、スレッドにチャネルを提供してメッセージを取得します。必要に応じて CloseConnection を呼び出して、アプリケーションが正常に動作することを確認してください。または IDisposable を実装します。
• 将来、RabbitMQ が別のものに置き換えられる可能性は小さいですが、そのため、インターフェイスをその特定のサービス バスに限定しすぎないようにしたいと考えています (これが私が使用している方法であるという意味で)。実装。

同様のアプリケーションを構築するときに、他の誰かがすでに同じ課題に取り組んでいましたか? メッセージ キューへのインターフェイスのアーキテクチャと実際の実装について何かアドバイスはありますか? 私はこれについて神経質になっているだけですか、それとも私の心配は認める価値がありますか?

問題があれば、現在のメッセージングのニーズは一方向のメッセージでカバーされており、処理が完了したら受信したメッセージを確認する以外に応答は必要ありません。

洞察をありがとう！

AMQPとRabbitMQについて学び始めています。

自分自身を動かすために、CLIツールrabbitmqadminを使用して、MacOSXボックスで作成したRabbitMQ開発インストールにデータを正常に公開しました。これまでのところ、メッセージを公開して、それらがデキューされるのを見ることができます...

ただし、Heroku / CloudAMQPインスタンスでまったく同じ機能を試してみると、rabbitmqadminクライアントが失敗しているようです。

これは呼び出しです：

...そしてこれは出力です：

どんな考えやアイデアもありがたく受け止めました！

Heroku にデプロイ済みの Django アプリがあります。このアプリはメッセージ キューイングに Celery を使用しており、RabbitMQ を使用してローカルで問題なく実行しました。

残念ながら、この赤ん坊を Heroku にデプロイしようとしたとき、RabbitMQ アドオンが利用できず、CloudAMQP を使用する必要があることがわかりました。CloudAMQP と Heroku の両方のドキュメントを見ると、Celery を使用できると思われます (彼らは Pika を推奨していますが) が、デプロイしようとすると、スケジューラーとワーカー プロセスの両方でひどい接続エラーが発生します。正確なエラーは次のとおりです。

私の Heroku 設定変数には CLOUDAMQP_URL があることに注意してください。問題にはなりませんか?

CloudAMQP を Django/Heroku で使用したことがある方がいらっしゃいましたら、Celery がブローカーに確実に接続できるようにする方法を教えていただければ幸いです。

MassTransitをAppHarborとCloudAMQPで正常に動作させることができた人はいますか？

私はそれで時間のクマを持っています。

パブリッシャー（Webサイト）にメッセージを送信させていますが、サーバー（バックグラウンドワーカー）がメッセージを受信して​​いないようです。

私が懸念していることの1つは、MTがrabbitmqスキームを必要とするのに対し、CloudAMQPはスキームをamqpに設定することです。

バスを構成するときにスキームを（amqpからrabbitmqに）交換していますが、メッセージのアドレスのスキームがrabbitmqであることに気付きました。これは、置き換えたので意味があります。しかし、サーバーがそれらを取得するために、それらがamqpである必要があるかどうか疑問に思っていますか？

これは私が送信した簡単なメッセージです。RabbitMQに届きましたが、サーバーはそれを取得していません。

ありがとう、ジョー

編集：URLでパスワードを指摘してくれたCarlに感謝します

AppHarbor アプリケーションから CloudAMQP LEMUR で Masstransit を使用しようとしていますが、例外が発生します。

「指定されたエンドポイントに到達できませんでした」

Masstransit の構成方法は次のとおりです。

私が使用しているバージョンは次のとおりです。 MassTransit 2.6.3
MassTransit.RabbitMQ.2.6.3
RabbitMQ.Client.2.8.7
Magnum.2.0.1.0

このエラーを解決するにはどうすればよいですか?

ありがとう

Appfogなどの他のクラウドソリューションからCloudAMQPによってrabbitmqサービスにメッセージを公開し、インターネット（クラウド内ではない）からそれらを消費することは可能ですか？

排他的キュー (一度に許可されるコンシューマーは 1 つだけ) にサブスクライブすると、キューがオーバーサブスクライブされる (既にコンシューマーがある) 場合、node-amqp は例外をスローします。

• .on("error",cb) 構文を使用してみました。
• エラー ドメインを試しました (ノード 0.10.0)
• try/catch は明らかに機能しませんでした

これが私のサブスクリプション ラインですが、特別なことではありません。

キューが使用中の場合、未処理の例外がスローされます。

node-amqp の内部を見ると、エラーが発生したときにタスクが独立したコンテキストで実行されるように、モジュール内に独立したタスク キューが実装されていることがわかります。

回避策/修正はありますか? ...または私は何か間違ったことをしていますか?