Servidor SQL, usando una tabla como cola

Question

Estoy usando un SQL Server 2008 R2 como un mecanismo de cola. Agrego elementos a la tabla, y un servicio externo lee y procesa estos elementos. Esto funciona muy bien, pero falta una cosa: necesito un mecanismo mediante el cual pueda intentar seleccionar una sola fila de la tabla y, si no hay una, bloquear hasta que esté (preferiblemente durante un período de tiempo específico).

¿Alguien puede aconsejarme sobre cómo podría lograr esto?

Answer 1

necesito mecanismo por el cual puedo intentar para seleccionar una sola fila de la tabla y, si no hay uno, bloque hasta hay (preferiblemente durante un periodo específico de tiempo).

Puede recorrer y comprobar si hay nuevas filas por segundo:

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

responsabilidad: esto no es un código que yo usaría para un sistema de producción, pero sí lo que se le pregunte.

Answer 2

El comentario anterior que sugirió usar Service Broker probablemente tuvo la mejor respuesta. Service Broker le permite bloquear esencialmente mientras espera más entrada.

Si Service Broker es excesivo, debe considerar un enfoque diferente para su problema. ¿Puede proporcionar más detalles de lo que está tratando de hacer?

Answer 3

La única forma de lograr una dequeue de bloqueo no agrupada es WAITFOR (RECEIVE). Lo que implica colas de Service Broker, con todos los gastos generales añadidos.

Si está utilizando el ordinario tables as queues, no podrá lograr el bloqueo sin polling. Debe sondear la cola solicitando una operación de dequeue, y si no devuelve nada, duerma e intente de nuevo más tarde.

Me temo que voy a estar en desacuerdo con Andomar aquí: mientras que su respuesta funciona como una pregunta genérica '¿hay alguna fila en la tabla?' cuando se trata de hacer cola, debido a la naturaleza ocupada de la superposición de enqueue/dequeue, la comprobación de filas como esta es un punto muerto (casi) garantizado bajo carga. Cuando se trata de usar tablas como cola, uno siempre debe apegarse a las operaciones básicas de enqueue/dequeue y no intente con cosas sofisticadas.

Answer 4

"desde que SQL Server 2005 introdujo la cláusula OUTPUT, el uso de tablas como colas ya no es un problema difícil". Una gran publicación sobre cómo hacer esto.

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

Answer 5

Permítanme compartir con ustedes mis experiencias en esta área, puede que le resulte útil.

Mi equipo utilizó por primera vez las colas transaccionales de MSMQ que alimentarían nuestros servicios asíncronos (ya sea IIS alojado o WAS). El mayor problema que encontramos fue problemas de MS DTC bajo una gran carga, como más de 100 mensajes/segunda carga; todo lo que se necesitó fue una operación de base de datos lenta en algún lugar para comenzar a causar excepciones de tiempo de espera y MS DTC derribaría la casa por así decirlo (las transacciones se perderían si las cosas empeoraban), y aunque no estamos 100% seguros de la raíz porque hasta el día de hoy sospechamos que MS DTC en un entorno agrupado tiene algunos problemas graves.

Debido a esto, comenzamos a buscar diferentes soluciones. Service Bus para Windows Server (la versión in situ de Azure Service Bus) parecía prometedor, pero no transaccional, por lo que no se ajustaba a nuestros requisitos.

Finalmente nos decidimos por el enfoque "roll-your-own", un enfoque que nos sugirieron los chicos que construyeron el Azure Service Bus, debido a nuestros requisitos transaccionales. Básicamente, seguimos el modelo de Rol de trabajador de Azure para un rol de trabajador que se alimentaría a través de una cola; un modelo de bloqueo de sondeo

Honestamente, esto ha sido mucho mejor para nosotros que cualquier otra cosa que hayamos usado. El pseudocódigo para este tipo de servicio es:

hasMsg = true 

while(true) 

    if(!hasMsg) 
     sleep 

    msg = GetNextMessage 

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

    Process(msg); 

Hemos encontrado que el uso de la CPU es menor significativamente de esta manera (más bajo que los servicios tradicionales de WCF).

La parte difícil, por supuesto, es el manejo de las transacciones. Si desea que varias instancias de su servicio se lean desde la cola, deberá emplear read-past/updlock en su sql, y también hacer que su servicio .net se aliste en las transacciones de una manera que se extenderá. volver si el servicio falla. en este caso, querrá ir con las colas de reintento/envenenamiento como tablas además de sus colas habituales.