Лучший способ поставить в очередь сообщения в SQL Server с несколькими авторами и одним читателем

Question

Лучший способ поставить в очередь сообщения в SQL Server с несколькими авторами и одним читателем

Я хочу создать очередь, в которую будет писать множество компьютеров, но каждый компьютер будет писать только один раз за всю свою жизнь. Как вы думаете, будет ли лучший способ достичь этого?

Я читал об очередях SQL Server, таблицах SQL Server, используемых в качестве инфраструктуры очередей или посредников служб.

Таблица SQL Server: довольно легко создать, но я боюсь производительности
Сервисный брокер: более сложная инфраструктура. Кажется, вам нужно запустить службу для отправителя и иметь очередь отправки, которая в моем случае бесполезна, потому что все они отправляют только одно сообщение за всю свою жизнь.

Какое решение будет лучшим в моем случае?

0

sql message-queue service-broker

Источник

user1594047 30 июн '13 в 18:12

3 ответа

Другие вопросы по тегам sql message-queue service-broker

user1047231 30 июн '13 в 18:58 2013-06-30 18:58 · Answer 1 · 2013-06-30 18:58

Вам не нужно создавать службу на каждом компьютере. Объекты компонента Service Broker могут быть ограничены одним сервером БД. Например, если у вас есть 100 компьютеров, которым необходимо удалить сообщение, им потребуется строка подключения к серверу базы данных и выполнение хранимой процедуры, которая поставит в очередь указанное сообщение.
Тем не менее, кажется, что очередь Service Broker будет излишним для этого. Вероятно, будет достаточно простой таблицы или, что еще лучше, MSMSQ (что исключит необходимость подключения к БД).

user716684 11 июл '13 в 09:31 2013-07-11 09:31 · Answer 2 · 2013-07-11 09:31

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

user2503659 30 июн '13 в 21:28 2013-06-30 21:28 · Answer 3 · 2013-06-30 21:28

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

Наш код не требует более нескольких сотен транзакций в секунду, и я показал, что наша очередь может достигать более 10 000 транзакций в секунду, поэтому я довольно доволен производительностью.

Вот отличная статья, описывающая, как создавать таблицы для использования в качестве очередей: http://rusanu.com/2010/03/26/using-tables-as-queues/

Я бы не стал оформлять ваш стол без предварительного прочтения.

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