質問

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

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

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

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

これは、SQL Service Brokerで実装できるものですか?私は間違った方向に向かっていますか?

ありがとう!

役に立ちましたか?

解決

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

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

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

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

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top