MSMQ並行処理設計の問題

Question

MSMQから読み取り、ワーカースレッドでそのメッセージを処理するエージェントに割り当てるメッセージの種類に基づいて、C＃で書かれたWindowsサービスがあります。エージェントのワーカースレッドが仕事をしてビジー状態の場合

：アプリケーションはここにそれがどのように動作するかの基本的な数字があるなしエージェントで始まり、メッセージがMSMQ

に到着すると、実行時に動的に作成されていますメッセージはローカルキューにキューイングされます。ここまでは順調ですね。しかし、何らかの理由でサービスが停止した場合、ローカルキューの内容は失われます。

私はこのシナリオを処理する最良の方法が何であるか把握しようとしています。現在、ローカルキューはSystem.Concurrent.ConcurrentQueueです。私はおそらく、Sql Ceのdbまたはその他の永続的なストレージを使用することができますが、私はパフォーマンスが心配です。もう1つのことは、エージェントがメッセージを処理する準備ができているときだけMSMQから読むことですが、MSMQに含まれるメッセージがわからないという問題があります。

この問題を解決するには、どのような方法がありますか？

Answer 1

私はRedisに依存する同様のシステムを構築しました。そのアイデアは、メモリ高速データアクセスをアプリケーションの他の部分から隔離して提供し、サービスが動作するときにはシャットダウンしないということです。さらに、最終的にはデータをディスクに保存するため、信頼性とスピードの間に優れた妥協点が得られます。

各クライアントがRedisでホストされる独自のメッセージキューから読み取るように設計した場合は、キューをサービスのダウンタイムから独立させ、次回のサービス開始時に各ワーカーの負荷を配分できます。

Answer 2

Agentaとagentbのメッセージを受け取る2つの新しいmsmsキューを作成し、メインのキューからコマンドをフェッチして適切なエージェントキューにメッセージをディスパッチする新しいエージェントを作成するのはなぜですか？

Answer 3

あなたのデザインは基本的に以下のパターンを実装します：http://www.eaipatterns.com/MessageDispatcher.html

しかし、あなたはマルチスレッドコードでディスパッチャを実装するために選択されている、むしろ実際のメッセージングを使用するよりも。

むしろ、各処理エージェントは、独自の物理メッセージキューを持つ自律プロセスでなければなりません。これが失敗の場合のメッセージ耐久性を提供するものです。また、処理エージェントのインスタンスをさらにホストすることで、規模を拡大することもできます。