トランザクションにMSMQまたはSQL Service Brokerを使用する必要がありますか？

Question

チームリーダーから、新しいバージョンの製品のオプションとしてMSMQを調査するように依頼されました。現在のバージョンではSQL Service Brokerを使用しています。どの製品が自分のニーズに合っているかを見つけるために、実験とグーグルのかなりの部分を共有しましたが、プログラミングの答えについては、私が知っている最高のサイトを尋ねると思いました。

いくつかの詳細：

• クライアントは.NET 1.1および2.0コードです。ここからメッセージが送信されます。
• SQL Server 2005インスタンスのターゲット。すべてのメッセージは、データベースの更新または挿入になります。
• トランザクションとして扱う必要のあるいくつかの更新を送信します。
• メッセージの完全な回復性が必要です。メッセージを失うことはありません。
• ターゲットのSQLサーバーがダウンしていても、非同期でメッセージを受信できる必要があります。
• 独自のキューイングソリューションを開発することは選択肢ではありません。私たちは小さなチームです。

これまでに発見したこと：

• MSMQとSQL Service Brokerの両方がジョブを実行できます。
• トランザクションブローカの場合、Service Brokerはより高速であるようです。
• Service Brokerでは、どこかで実行されているSQLサーバーが必要ですが、MSMQでは、どこかで実行されている構成済みのWindowsマシンが必要です。
• MSMQは、クラスターでのセットアップ/実行の方が優れている/速い/簡単なようです。

何か不足していますか？ここに明確な勝者はいますか？考え、経験、またはリンクはすべて評価されます。ありがとう！

編集：クライアントコードの一部でカスタムDBフレームワークが使用されているため、サービスブローカーに固執しました（トランザクションをより適切に処理します）。そのコードはトランザクションのSQLをキャプチャしましたが、ではありません。クライアントコードもすべて.NETのバージョン1.1であったため、すべてのクライアントコードをアップグレードする必要がありました。ご協力ありがとうございます！

Answer 1

アプリケーションをService BrokerからMSMQに移行しただけで、MSMQの使用に投票する必要があります。考慮すべき要因がいくつかありますが、そのほとんどはデータの使用方法と処理の場所に関係しています。

• データベースで処理が行われる場合 Service Broker
• データの移動だけの場合は？ Service Broker
• 処理は.NET / COMコードで行われますか？ MSMQ
• リモート分散トランザクション（たとえば、SQLとは異なるボックスでの処理）が必要ですか？ MSMQ
• 宛先がダウンしているときにメッセージを送信できるようにする必要がありますか？ MSMQ
• nServiceBus、MassTransit、Rhino-ESBなどを使用しますか？ MSMQ

何を選択しても考慮すべき事項

• キューの状態をどのように知っていますか？どちらのオプションもフェイルオーバーの処理方法が異なります。たとえば、 Service Broker は、アプリケーションをダウンさせる可能性がある特定のシナリオでキューを無効にします。
• レポートをどのように実行しますか？レポートで既にSQLテーブルを使用している場合、 Service Broker は別の動的テーブルであるため、簡単に適合できます。既にパフォーマンスモニターを使用している場合は、 MSMQ がより適している場合があります。 Service Broker には多くのパフォーマンスカウンターがあるため、これを唯一の要因にしないでください。
• アップタイムをどのように測定しますか？トランザクションが失われないようにするだけですか、それとも同期的に応答する必要がありますか？メインキューはオフラインになり、何も失わないため、 MSMQ の分散された性質により、稼働時間が長くなります。一方、 Service Broker を使用する場合は、データベースをオンラインにする必要があります。そうしないと、失うことになります。
• これらのテクノロジーのいずれかを既に使用したことがありますか？どちらにも実装の詳細がたくさんあり、戻ってきて噛み付くことができます。
• どのような選択をしても、基礎となるキューイングテクノロジーを簡単に切り替えることはできませんか？具体的な実装を作成する汎用のIQueueインターフェイスを使用することをお勧めします。このように、間違った選択をしたことがわかった場合、後から簡単に選択を変更できます。結局、キューは単なるキューであり、特定の実装に縛られるべきではありません。

Answer 2

以前にMSMQを使用したことがあり、リストに追加する唯一の項目は、バージョン管理の前提条件チェックです。 1つのサイトにWin 2000 Serverが存在し、MSMQ v.2とWin 2003 ServerおよびMSMQ v3が存在するという問題に遭遇しました。私のすべての.NETコードはv.3を対象としており、互換性がありません...または少なくとも簡単にはそうではありません。

MSMQルートに行く場合は考慮事項です。

Answer 3

MSMQのメッセージサイズの制限により、その方向での調査が停止しました。プロジェクトのService Brokerを学んでいます。

Answer 4

  

宛先がダウンしている間にメッセージを送信できるようにする必要がありますか？ MSMQ

理由がわかりませんか？ SSBは、切断された宛先に問題なくメッセージを送信できます。このメッセージはすべて送信キューに送信され、宛先が到達可能な状態になったときに配信されます。