1

ServiceBroker を評価して、非常に特定のコンテキストで信頼できるキューとして機能できるかどうかを判断し始めたところです。シナリオは次のとおりです。

(1) 計算コストの高い値の大規模な (数百万) 母集団を事前に計算し、キューに格納する必要があります。

(2) 複数のプロセスが、必要に応じて実行時にこれらの値の読み取り/キューからの取り出しを試みます。毎秒数百以上の読み取りになる可能性があります。

(3) モニター プロセスは、ときどきキューをポーリングし、人口の最小しきい値に達したかどうかを判断し、キューを再移植します。

一部のインフラストラクチャ/コストの制約により、産業用強度のキュー (websphere) は選択肢にならない場合があります。Service Broker についてこれまで見てきたことは、2 つのエンドポイントとの "会話" に分離されているように見え、私のシナリオでは、書き込みとは完全に独立して読み取りが行われるため、心強いものではありません。これが SQL Service Broker で可能かどうかについての洞察はありますか?

4

1 に答える 1

0

Service Broker はそのようなシナリオ向けには設計されていませんが、少し調整すればうまくいくと思います。

1 つのアプローチは、会話のプールを事前に作成し、値を保存するときにこれらの会話間で計算プロセスをラウンドロビンにすることです。キューから受信すると会話がロックされるため、本質的に会話の数によって、値を同時にデキューできるプロセス数の上限が設定されます。それについてはよくわかりませんが、受信側で受信する会話を明示的に伝えるロジックが必要になる場合があります（デフォルトの受信動作よりも優れた負荷分散を実現するため）。

パフォーマンスが問題にならない場合は、会話プールのアイデアを破棄して、個別のダイアログで各メッセージを送信することもできます。これにより、パフォーマンスが大幅に低下しますが、実装が簡単になります。

上記はすべて、値がランダムな順序でキューから取り出される可能性があることを前提としています。それ以外の場合は、単一の会話を使用して受信順序を保証する必要があります。

于 2010-07-19T07:07:09.090 に答える