sql-server - habilitar - sql 2017 service broker

Sql Server Service Broker: ¿Cómo estructurar conversaciones para un escenario de cola simple?

Question

Soy un novato de Sql Server Service Broker y estoy tratando de comprender la mejor manera de configurar Service Broker para un caso de uso (aparentemente) simple: quiero crear una cola de trabajo simple, donde una aplicación coloca elementos de trabajo en el la cola, y la aplicación separada recoge los elementos de trabajo de esa cola y los procesa. No es necesario que la primera aplicación recupere los mensajes de estado de la segunda. Quiero que la cola viva en una sola instancia de Sql Server.

Lo que más me confunde es cómo las conversaciones / diálogos se relacionan con esta situación. Sé que solo puede enviar / recibir mensajes en el contexto de una conversación / diálogo, pero como no hay una conversación entre las dos aplicaciones, me siento perdido cuando es el momento adecuado para crear una nueva conversación. Las dos alternativas extremas parecen ser:

• Cada vez que pongo en cola un elemento de trabajo, comienzo una nueva conversación. Así que cada conversación termina teniendo exactamente un mensaje en ella.
• En el momento del despliegue, creo manualmente una sola conversación de duración infinita. Cuando llega el momento de poner en cola un elemento de trabajo, siempre lo envío como parte de esa única conversación.

¿Cuáles serían las consecuencias de ir por cualquiera de estas rutas?

Además, en el primer caso, parece que necesito hacer algunas CONVERSACIONES FINALES para que el servidor SQL pueda limpiar los recursos internamente. ¿Hay alguna orientación sobre cuándo sería el lugar correcto para colocarlos? (¿O podría ser mejor confiar en el tiempo de espera de las conversaciones con el tiempo?)

Answer 1

Debe comenzar con cada elemento de trabajo en su propia conversación. El productor (iniciador) comienza un diálogo y envía el mensaje que describe el elemento de trabajo, luego se compromete. El consumidor (destino) recibe el mensaje (o se activa), inspecciona la carga útil para comprender los detalles del elemento de trabajo, ejecuta el trabajo, luego finaliza el cuadro de diálogo y confirma. El mensaje EndDialog resultante se envía de vuelta a la cola de servicio del iniciador, y un procedimiento activado en la cola del iniciador responde al finalizando el cuadro de diálogo en el lado del iniciador.

Esta es la implementación más simple, y ponerla en funcionamiento se asegurará de que tenga una base sólida sobre la cual construir. No corte las esquinas y finalice el cuadro de diálogo en el lado del iniciador desde que el productor pone en cola el elemento de trabajo, esto es fuego y olvido y tiene varios inconvenientes .

Si tiene requisitos de alto rendimiento (más de 200 solicitudes por segundo), tendrá que comenzar a administrar las conversaciones de manera más explícita. Tengo una entrada de blog sobre la reutilización de conversaciones por motivos de rendimiento . En el lado de recepción, recomiendo leer los Procedimientos de los Corredores de Servicios de Escritura .

También tengo una entrada de blog que hace prácticamente lo que necesitas, aunque no programa elementos de trabajo, sino que inicia un procedimiento personalizado: Ejecución de procedimientos asíncronos .

Si decide consumir los elementos de trabajo de un contexto activado, aprovechando así las agradables capacidades de auto equilibrio de la activación, debe comprender el contexto EJECUTAR COMO en el que se produce la activación .

Answer 2

Me gusta mucho la respuesta de Remus, aunque no toca especialmente el motivo por el que prefieres iniciar una conversación separada por elemento de trabajo, en lugar de poner todos los elementos de trabajo en una sola conversación. Dos notas relacionadas con esto:

Primero, colocar todos los elementos de trabajo en una sola conversación probablemente causará problemas de concurrencia si tiene múltiples subprocesos / procesos que procesan elementos de trabajo. Los procesos de trabajo de Service Broker tienden a verse así (en pseudocódigo):

begin transaction
receive top n work items from queue
process work items
commit transaction

(Al no confirmar hasta que los elementos de trabajo se procesen correctamente, se asegura, por ejemplo, que si su proceso muere, los elementos de trabajo que ha recibido pero que aún no se han procesado no se eliminarán de la cola).

El problema de concurrencia surgiría porque el agente de servicio está programado de tal manera que cada comando RECEIVE adquiera un bloqueo de lectura exclusivo en todos los mensajes en la cola que comparten la misma conversación (o grupo de conversación) que los REEIVEd. Ese bloqueo se mantiene hasta que se comprometa la transacción. (Consulte Bloqueos de grupos de conversación ). Entonces, si todos los elementos de trabajo en la cola están en una sola conversación, mientras que un proceso de trabajo se encuentra en el paso de "elementos de trabajo de proceso", ningún otro proceso de trabajo puede realizar ningún trabajo.

Un segundo problema al poner muchos elementos en una sola conversación es que aumenta la cantidad de elementos de trabajo que podría perder o que tendría que reprocesar en ciertas condiciones de error. Para describir esto apropiadamente, cedo a Remus; vea sus Conversaciones de reciclaje , especialmente la parte que dice "reutilizar un solo cuadro de diálogo para enviar todos sus mensajes [...] es como poner todos sus huevos en una canasta". Es posible que pueda recuperarse de algunas de estas situaciones de error, pero probablemente introducirá una mayor complejidad en su código.

Es probable que haya algunos argumentos más contra el uso de una sola conversación para todos los elementos de trabajo, pero no estoy tan familiarizado con ellos.

Esto no quiere decir que la solución correcta sea siempre iniciar una conversación separada para cada elemento de trabajo. Después de haber leído las publicaciones de Remus, su consejo parece acertado; comience con un elemento de trabajo por conversación, y luego agregue complejidad si es necesario. (Pero probablemente en ningún caso deberías llegar al extremo de poner todos los mensajes en una sola conversación).