我々は、.NET RabbitMQのライブラリを使用して次のシナリオを持っている：マルチスレッド.NETのRabbitMQ出版社
ワーカースレッドがキューから「要求」メッセージをピックアップし、処理のために複数のワーカースレッドにディスパッチします。完了すると、各ワーカースレッドは別のメッセージを送信します。
私の質問は、最高のスループットと安定性を得るために、送信者にはどのようなパターンが推奨されますか。例：単一の接続とIModelを持つすべてのワーカースレッドによってアクセスされる
1）シングルトン「パブリッシャ」インスタンス（「ロック」IModelをへのアクセスを同期するために）
2）シングルトン 'を使用して1つのConnectionですべてのワーカースレッドからアクセスされ、各送信要求に対して新しいIModelを作成する「発行者」インスタンスです。
などですか？
RabbitMQユーザーガイドによると、「複数のスレッドが同時にIModelインスタンスを使用しないでください。アプリケーションコードはIModelインスタンスのスレッド所有権の明確な概念を維持する必要があります」 IModelが共有される場合は、あなたが言ったが、私の意見では、これはより複雑なコードにつながります。なぜなら、接続やモデルは切断の際に生き続けるべきだからです。
メッセージ配信の信頼性を高めるためにトランザクションが必要かどうかは言及していませんが、チャネルはトランザクションモードで設定する必要があります。また、配信ごとにトランザクションが必要になることもあります。
配信ごとに新しいモデルを使用すると、より単純なエラー管理が保証されますが、 は明らかにスループットを低下させます（トランザクションを使用しても同様です）。
要件に応じて、耐久性のないキューと直接スループットを提供するファンアウト交換を使用することもできます。
例として、開発マシン上では、単一のスレッドを使用してキューからメッセージを消費するWindowsサービス（デシリアライズ、ビジネスロジックの作成、コネクションのオープンとクローズによるトランザクションを使用した新しいシリアル化メッセージの送信） （シリアル化はDataContractSerializerよりも悪いXmlSerializerで行われました）
ありがとう - ここにいくつかの役に立つポインタがあるので、これを受け入れられた答えに印を付けるつもりです。記録のために、実際の送信を行うために共有キューと内部スレッドを使用する「非同期」送信側を構築することを検討しています。 –
いくつかの試行錯誤のために良い問題のように聞こえます。 –
各ワーカースレッドは、中央プロセスdistを持つ代わりにメッセージキューからメッセージを取得する方が良いでしょう作業をスレッドにリブートします。メイン・プロセスが作業項目を置くことができ、ワーカー・スレッドがそれらを受け取る共有メモリー・キュー（RabbitMQ libにスレッドセーフ実装があります）を使用して、あなたが提案していることを達成することができます。 –
Thx both.Chris：それは、他の人々の実際の経験を本当に望んでいた。 –