4

アプリケーションでRabbitMQをESBとしてMassTransitを使用して調査しています。私が探している主な利点は、永続的な非同期メッセージング処理を着信データ ストリームに追加することです。

アプリケーション プロファイルには 2 つの部分があります。

着信データ ストリーム

  • 一方向メッセージ
  • 非同期処理
  • 1 分あたり 1 万件以上のメッセージ

ウェブサイトの活動

  • 双方向
  • 理想的には c# async await 言語機能を使用しますが、双方向のデータが必要です
  • < 100/分

Web アプリのメッセージングは​​必須ではありませんが、同じメカニズムに従って、ESB を介したデータ アクセスを完全に抽象化するとよいでしょう。

質問:

私が読んだことから; ESBノードは、バス上の他のノードを認識したり、気にしたりしてはなりません。自分の仕事をしてバスにメッセージを送信し、必要に応じて応答を待つ必要があります。私にとって、これは、各 Web/アプリケーション サーバーが独自のローカル クラスター キューを持つことを意味します。この仮定は正しいですか？

それが正しい場合。プログラムでマシンをクラスターに追加するにはどうすればよいですか? 注意が必要な落とし穴はありますか?

これが正しくない場合。キュー クラスタをどのように管理しますか? 専用クラスターの作成には、DNS エントリ、冗長性/オフライン ノードの負荷分散など、独自の問題があります。

私は ESB が MassTransit の実装と共に追加できる機能に落ち込んでいますが、耐久性のある構成でそれをどこでどのようにセットアップするかのベスト プラクティスのロジスティクスに少し戸惑っています。

フィードバックとアドバイスをありがとう

更新 マシン インフラストラクチャに EC2 を利用しています。特に、アベイラビリティ ゾーンを使用して、データ センターの停止を最小限に抑えています。この構成では、3 つのゾーンがあり、各ゾーンには Web サーバー、アプリ サーバー、DB サーバー (Couchbase) があります。また、EC2 のロード バランサーを使用して、ゾーン間で負荷を共有しています。

@Travis: Amazon の EC2 内で MT / RMQ を使用した経験 / アドバイスはありますか?

4

2 に答える 2

3

そのため、お客様の規模よりもはるかに大きな規模で、負荷分散 (F5) の背後にある RabbitMQ クラスターがあります。MT を使用するすべてのプロセスは、負荷分散されたアドレスを参照します。各プロセスが必要とするのは、受信元の独自のキューだけです。

RabbitMQ (3.0+) でのクラスタリングはすべて、RabbitMQ 構成で処理されます。プロセス/コードはクラスタリングについて何も知りません。

この質問の「ノード」の意味がわからないので、正しい質問に答えているかどうかを確認するのは困難です。しかし、RabbitMQ でプロセスを同じ仮想ホスト (デフォルトまたはそれ以外) に追加するとすぐに、MT は必要なすべての要素 (交換、キュー、バインディング) を接続します。

于 2013-09-17T12:08:52.940 に答える
1

私たちはトラヴィスに対して別のアプローチをとっています。メッセージを消費/処理または発行するサービスを持つすべてのマシンは、RabbitMq クラスター内のノードでもあります。すべてのマシンは、localhost 経由で RabbitMq に対処するだけで済みます

各サービスは複数のマシン上にあります。これを実現するために、競合するコンシューマーを使用しています (つまり、複数のマシンが同じクラスター化されたキューから (ただし localhost 経由で) 読み取ります)。したがって、アーキテクチャはメッセージの並列処理を許可する必要があります。

1 台のマシンがダウンした場合、停止したマシン サービスを実行している別のマシンが少なくとも 1 つあります。

多くのマシンがダウンした場合、すべてのメッセージが保存されている他のマシンがあり、それらにサービスをデプロイできます。

于 2013-09-26T12:27:55.600 に答える