25

チーム リーダーから、製品の新しいバージョンのオプションとして 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 だったので、すべてのクライアント コードをアップグレードする必要がありました。ご協力いただきありがとうございます！

4

4 に答える 4

34

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

  • データベースで処理を行う場合は? サービスブローカー
  • 単なるデータ移動の場合は？サービスブローカー
  • 処理は .NET/COM コードで行われますか? MSMQ
  • リモート分散トランザクション (SQL とは異なるボックスでの処理など) が必要ですか? MSMQ
  • 宛先がダウンしている間にメッセージを送信できる必要がありますか? MSMQ
  • nServiceBus、MassTransit、Rhino-ESB などを使用しますか? MSMQ

何を選ぶにしても気をつけたいこと

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

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

MSMQ ルートを使用する場合の考慮事項です。

于 2008-10-27T18:55:33.247 に答える
3

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

于 2009-11-23T03:12:27.987 に答える
1

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

なぜだか分からない？SSB は切断された宛先に問題なくメッセージを送信できます。このすべてのメッセージは送信キューに送られ、宛先が到達可能な場合に配信されます。

于 2010-08-19T08:07:06.803 に答える