web-dev-qa-db-ja.com

SQL Server Service Brokerの欠点

現在のメッセージングソリューションMSMQを置き換えるために、SQL Server Service Brokerの範囲の研究開発を行っています。次の基準について、MSMQとは対照的にSQL Server Service Brokerの欠点を知りたいです。

  1. 開発
  2. トラブルシューティング
  3. パフォーマンス（1日あたり100,000件のメッセージを処理する必要があるとします。平均サイズは約25 KBです）
  4. 拡張性
sql-servermsmqmessage-queueservice-broker
19
mit

私は現在のプロジェクトでService Brokerを使用していますが、以前はMSMQ（ MassTransit で仲介されていました）を使用して大成功を収めました。私は当初、Service Brokerの使用について疑っていましたが、非常にうまく機能していることを認めなければなりません。

パブリッシュ/サブスクライブモデルを使用している場合は、毎回メッセージキューを使用します（ただし、プロジェクトで許可されていればRabbitMQ over MSMQを使用します）。 、Service Brokerは優れたソリューションです。「金属に近い」という事実は大きな利点です。

開発

Service Brokerには大量のボイラープレートが必要です。これは苦痛ですが、多くの異なるキューを用意することを計画していない限り、管理は可能です。 Visual StudioのSql Serverプロジェクトは、展開するのに苦労します。

トラブルシューティング

Service Brokerはブラックボックスです-メッセージが送信され、通常は送信されますが、そうでない場合はトラブルシューティングが問題になる可能性があり、できることは システムビューのクエリ -そして時々単に何が間違っていたかを見つけることができません。これは迷惑ですが、MSMQにも同じような問題があります。

パフォーマンス

Service Brokerのパフォーマンスは優れています。 SLAロード時に1日あたり100,000を超えるメッセージ、1時間あたり30,000を超えるメッセージを処理しています。メッセージサイズは大きいです。重負荷テスト。

最高のパフォーマンスを得るには、 this one のようなダイアログプールを使用することをお勧めします。 1 Service Brokerダイアログの作成として 費用のかかる操作になる可能性があります 。

Remus Rusanuが詳述したエラー処理手順 を使用することもできます。 （Service Brokerを使用する場合は、開始前にRemusが主題について書いたものをすべて読むこともできます。

スケーラビリティ

必要に応じて、複数のサーバーを使用してスケールアップすることができますが、そうする必要はありません。また、負荷の大きさから、どちらも必要ないと思います。

Service Brokerキューの不利な点を十分に強調していないため、私は本当にあなたの質問に答えることができたとは思いません。私は、その内部動作の不可解な性質が最も私を悩ますことだと思います-それが動作するとき、それは非常にうまく動作しますが、動作を停止すると、理由を理解することは非常に難しい場合があります。また、キューに多くのメッセージがある場合は、ALTER QUEUEの完了には非常に長い時間がかかります。

MSMQの使用方法がわからないということは、2つのテクノロジーを公正に比較することにも違いがあります。

1 元のURL が「無効」になり、ページがインターネットアーカイブにないため、Gistで再作成されました。最終的にコピーを見つけました ここ

34
stuartd