2

私は、着信メッセージを継続的に処理する .NET サービスの計画段階にいます。これには、さまざまな変換、データベースの挿入と更新などが含まれます。全体として、サービスは巨大で複雑ですが、実行する個々のタスクは小さく、シンプルで明確に定義されています。

このため、将来の簡単な拡張を可能にするために、サービスをいくつかの小さなサービスに分割して、基本的に処理の一部を実行してからチェーン内の次のサービスに渡したいと考えています。

これを実現するには、あるサービスから別のサービスにメッセージを渡す何らかの中間メッセージング システムが必要です。チェーン内のリンクがクラッシュしたり、一時的にオフラインになったりした場合に、宛先がオンラインに戻ったときにメッセージがキューに入れられて処理されるように、これを実現したいと考えています。

私は常にこの種のメッセージ キューイングを使用してきましたが、最近、同様のことを行うと思われる SQL Service Broker を認識しました。SQLSB はこのシナリオの実行可能な代替手段ですか? もしそうなら、標準のメッセージ キューの代わりに SQLSB を使用することでパフォーマンス上の利点が見られますか?

ありがとう

4

3 に答える 3

3

あなたはサービス バス アーキテクチャを求めているように思えます。これにより、探している調整とフォールト トレランスが提供されます。私は NServiceBus に最も精通しており、部分的に使用していますが、Mass Transit や Rhino Service Bus など、他にもあります。

于 2011-01-14T12:45:53.217 に答える
2

これらの手順のほとんどがデータベースの状態から始まり、データベースの更新に終わる場合は、メッセージストレージをデータストレージとマージすることは非常に理にかなっています。

  • バックアップ/復元する単一の製品
  • 一貫性のある状態のバックアップ
  • 単一の高可用性/災害復旧性ソリューション（DBミラーリング、クラスタリング、ログ配布など）
  • データベース規模のストレージ（メッセージストア製品の制限ではなく、データベース製品の特性に応じたIO機能、サイズ、容量の制限など）。
  • 調整、トラブルシューティング、管理する単一の製品

さらに、メッセージストアをデータストアと同じにすることで、メッセージのやり取りごとに2フェーズコミットを実行する必要がなくなるため、パフォーマンスに関する重大な考慮事項もあります。別のメッセージストアを使用するには、メッセージストアとデータストアを分散トランザクションに登録する必要があります（同じマシン上にある場合でも）。これには2フェーズコミットが必要であり、データベースのみのトランザクションのシングルフェーズコミットよりもはるかに低速です。

さらに、外部のものではなくデータベース内のメッセージストアを使用することには、クエリ可能性（メッセージキューに対してSELECTを実行する）などの利点があります。

ここで、「データベース内のメッセージストア」をService Brokerとして、「非データベースメッセージストア」をMSMQとして翻訳すると、SSBがMSMQの周りでいつでもサークルを実行する理由がわかります。

于 2011-01-15T20:14:31.653 に答える
1

私の最近の両方のアプローチ (Sql Server Service Broker から始めた) の経験から、SQL サーバーからメッセージを取得できなくて泣いてしまう状況に陥りました。問題は準政治的ですが、考慮したい場合があります。私の組織の SQL サーバーは専門の DBA によって管理されていますが、アプリケーション サーバー (NServiceBus などのメッセージング) は開発者とネットワーク チームによって管理されています。データベース サーバーに変更を加えると、DBA はパフォーマンス分析を行う必要があり、同じ空間にあるキューイング エンジンによって標準 SQL の責任が軽減されるのではないかという恐怖にどっぷりと浸かっています。

SSSB は管理が非常に困難ですが (メッセージング ミドルウェアとは異なります)、違いは、メッセージングの世界で何かを台無しにすることがより許可されていることです (発生する可能性のある最悪の事態は、メッセージの山がどこかに蓄積され、ログがいっぱいになることです)。顧客のトランザクション データが存在し、ビジネスに不可欠な SQL の世界 (レガシー システムのデータを含む) では、いかなる間違いも許されません。「予期しないデータベースの増加」、「待機時間アラート」、または「一時データベースが無限に成長している理由」という電子メールをもう受け取りたくありません。

アプリケーション サーバーが安価であることを知りました。メッセージ ハンドラを追加し、マシンを追加するだけです。簡単です。実質的にライセンス費用はかかりません。SQL サーバーでは、正反対です。メッセージングに Service Broker を使用することは、高価な車を使ってジャガイモ畑を耕すようなものだと私には思えます。他のことについてははるかに優れています。

于 2013-12-16T20:27:20.843 に答える