Использование SQL 2008 ServiceBroker для многопоточной безопасной очереди FIFO - PullRequest
1 голос
/ 15 июля 2010

Я только начинаю оценивать ServiceBroker, чтобы определить, может ли он работать как надежная очередь в очень специфическом контексте.Вот сценарий:

(1) необходимо предварительно рассчитать большую (несколько миллионов) совокупность вычислительно дорогих значений и сохранить в очереди.

(2) несколько процессов попытаютсячитать / удалять эти значения во время выполнения по мере необходимости.может составлять несколько сотен + операций чтения в секунду.

(3) процесс монитора будет время от времени опрашивать очередь и определять, достигнут ли минимальный порог населения, а затем повторно заполнять очередь.

Из-за некоторых инфраструктурных / стоимостных ограничений очередь промышленного уровня (веб-сфера) может не подойти.То, что я до сих пор видел в Service Broker, не внушает оптимизма, поскольку кажется, что оно изолированно от «разговора» с двумя конечными точками, и в моем сценарии мои чтения происходят совершенно независимо от моих записей.Кто-нибудь знает, возможно ли это с SQL Service Broker?

1 Ответ

0 голосов
/ 19 июля 2010

Хотя Service Broker не был разработан для таких сценариев, я думаю, что с небольшой настройкой он может работать в вашем случае.

Один из подходов заключается в том, чтобы предварительно создать пул разговоров, а затем провести циклический процесс расчета между этими разговорами при сохранении значений. Поскольку получение из очереди блокирует диалог, количество разговоров, по сути, устанавливает верхнюю границу количества процессов, которые могут одновременно исключать значения из очереди. Я не уверен в этом, но вам может потребоваться некоторая логика на стороне получателя, чтобы явно сказать, от какого разговора получить (для того, чтобы добиться лучшей балансировки нагрузки, чем получило бы поведение по умолчанию).

Если перфект не имеет значения, вы можете даже отбросить идею пула разговоров и отправить каждое сообщение в отдельном диалоге, что упростит способ реализации за счет существенного перфекта.

Все выше сказанное предполагает, что значения могут быть сняты в случайном порядке, в противном случае вам необходимо гарантировать порядок приема при использовании одного разговора.

...