SQL Server, используя таблицу как очередь

Question

Я использую SQL Server 2008 R2 в качестве механизма очередей. Я добавляю элементы в таблицу, а внешняя служба считывает и обрабатывает эти элементы. Это отлично работает, но не хватает одной вещи - мне нужен механизм, при котором я могу попытаться выбрать одну строку из таблицы и, если ее нет, заблокировать до тех пор, пока не будет (желательно в течение определенного периода времени).

Может ли кто-нибудь посоветовать, как я могу это достичь?

Answer 1

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

Вы можете петлю и проверить наличие новых строк каждую секунду:

while not exists (select * from QueueTable) 
    begin 
    wait for delay '00:01' 
    end 

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

Answer 2

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

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

Answer 3

Единственный способ добиться отказа от блокировки блокировки - WAITFOR (RECEIVE). Это означает, что очереди Service Broker со всеми добавленными накладными расходами.

Если вы используете обычный tables as queues, вы не сможете добиться блокировки без опроса. Вы должны опросить очередь, попросив операцию dequeue, и если она ничего не вернет, спать и повторить попытку позже.

Боюсь, что я не соглашусь с Андомаром здесь: в то время как его ответ работает как общий вопрос: «Есть ли какие-нибудь строки в таблице?» когда дело доходит до очередей, из-за насыщенного характера перекрытия enqueue/dequeue, проверка таких строк, как это, является (почти) гарантированным тупиком под нагрузкой. Когда дело доходит до использования таблиц в качестве очереди, нужно всегда придерживаться основных операций enqueue/dequeue и не пробовать причудливые вещи.

Answer 4

«поскольку SQL Server 2005 представил предложение OUTPUT, использование таблиц в качестве очередей больше не является трудной задачей». Отличная статья о том, как это сделать.

http://rusanu.com/2010/03/26/using-tables-as-queues/

Answer 5

Позвольте мне поделиться своим опытом с вами в этой области, вы можете найти полезным.

Моя команда впервые использовала транзакционные очереди MSMQ, которые будут поддерживать наши асинхронные службы (будь то IIS или WAS). Самая большая проблема, с которой мы столкнулись, - проблемы MS DTC при большой нагрузке, например, 100+ сообщений/вторая загрузка; все, что потребовалось, - это одна медленная операция с базой данных, где-то начинать вызывать исключения тайм-аута, а MS DTC приведет к тому, что дом будет так говорить (транзакции будут фактически потеряны, если все станет плохо), и хотя мы не на 100% уверены в корне причина по сей день, мы подозреваем, что MS DTC в кластерной среде имеет некоторые серьезные проблемы.

Из-за этого мы начали изучать различные решения. Служебная шина для Windows Server (локальная версия Azure Service Bus) выглядела многообещающей, но она была не транзакционной, поэтому она не соответствовала нашим требованиям.

Мы, наконец, решили использовать подход, основанный на вашем руле, который предложил нам ребята, которые построили Azure Service Bus из-за наших транзакционных требований. По существу, мы следовали за ролью роли «Лазурный рабочий» для рабочей роли, которая будет передаваться через некоторую очередь; модель блокировки опроса.

Честно говоря, это было намного лучше для нас, чем что-либо еще, что мы использовали. Псевдокод для такого сервиса:

hasMsg = true 

while(true) 

    if(!hasMsg) 
     sleep 

    msg = GetNextMessage 

    if(msg == null) 
     hasMsg = false 
    else 
     hasMsg = true 

    Process(msg); 

Мы обнаружили, что использование центрального процессора значительно снизить этот путь (ниже, чем традиционные услуги WCF).

Трудная часть, конечно, обработка транзакций. Если вы хотите, чтобы несколько экземпляров вашей службы читали из очереди, вам нужно использовать read-past/updlock в своем sql, а также иметь сервис .net, который зачисляет транзакции таким образом, назад, если служба завершится неудачей. в этом случае вы захотите пойти с повторными/ядовитыми очередями в виде таблиц в дополнение к вашим очередям.