0

私は野心的な Web アプリケーション プロジェクトに取り組んでいる初心者の Web 開発者です。

それで、いくつかの調査を行った後、SQL Service Broker について知りました。何とか使えそうですが、よくわかりません。それを学ぶには誰かが多くの時間を費やす必要があるので、それが自分のニーズに合っていることを確認したかった.

Web サイトのユーザーが Web サイトにテキストを送信できるシステムを実装する必要があります。このメッセージ ストリームは冗長で、FIFO 方式で処理する必要があります。ストリームの反対側では、別のユーザー グループがメッセージを処理します。

ここで、この最後のユーザー グループの 1 人が読んでいるメッセージは、他の誰も同時に読むことができないようにロックする必要があります。その後、ユーザーはメッセージを処理するかどうかを決定できます。彼がメッセージを処理することを決定した場合にのみ、メッセージをキューから削除できます。彼がメッセージを処理したくないと判断した場合、別のユーザーがそれを読んで決定できるように、メッセージをキューに戻す必要があります (キューの最後に、または少なくとも最高の優先順位で)。 .

これは SQL Service Broker で実装できるものですか? 私は間違った道を進んでいますか？

ありがとうございました！

4

1 に答える 1

1

IMO、Service Broker の最適な使用法は、疎結合の方法で独立したアプリケーションに接続することです。つまり、このように結び付けられたシステムは、相互に合意された一連のメッセージ タイプを介して通信できるということです。これは、たとえば、一方のアプリケーションが他方のデータベースを直接操作するのとは対照的です。

あなたが言ったことから、私はそれを単純なテーブルとして実装します。たとえば、ID PK、割り当てフラグ、およびカスタム列を使用してメッセージ テーブルを作成します。オペレーターが最後のメッセージをフェッチする場合は常に、Allocation = 'N' の最小 PK 値を取得し、Allocation を 'Y' に更新します。これを 1 回のトランザクションで行います。操作がメッセージをキューに戻すことを決定した場合は、その AllocationFlag を「N」に設定し、元に戻すだけです。

これはほんの一例です。この場合のデータベースは、一貫性、高負荷パフォーマンスなどを提供しています。

SSB に送信するすべてのデータは画面の背後でテーブルとして保存および操作されるため、必ずしもデータベース ソリューションよりも高速である必要はありません。

于 2009-05-08T14:49:28.287 に答える