Colas, temas y suscripciones de Service Bus

  • Artículo
  • Tiempo de lectura: 7 minutos

Azure Service Bus admite la puesta en cola de mensajes de confianza y mensajería de publicación y suscripción duradera. Las entidades de mensajería que forman el núcleo de las funcionalidades de mensajería de Service Bus son las colas, los temas y las suscripciones.

Importante

Si no está familiarizado con Azure Service Bus, lea ¿Qué es Azure Service Bus? antes de revisar este artículo.

Colas

Las colas ofrecen una entrega de mensajes según el modelo primero en entrar, primero en salir (FIFO [PEPS]) a uno o más destinatarios de la competencia. Es decir, los receptores normalmente reciben y procesan los mensajes en el orden en el que se agregaron a la cola. Además, solo un destinatario de mensaje recibe y procesa cada uno de los mensajes.

Imagen que muestra cómo funcionan las colas de servicio.

La principal ventaja del uso de colas es conseguir un desacoplamiento temporal de los componentes de la aplicación. En otras palabras, los productores (remitentes) y los consumidores (receptores) no tienen que enviar y recibir mensajes al mismo tiempo. Esto se debe a que los mensajes se almacenan de manera duradera en la cola. El productor no tiene que esperar una respuesta del destinatario para continuar el proceso y el envío de mensajes.

Una ventaja relacionada es la nivelación de la carga, lo que permite a los productores y consumidores enviar y recibir mensajes con distintas velocidades. En muchas aplicaciones, la carga del sistema varía con el tiempo. Sin embargo, el tiempo de procesamiento necesario para cada unidad de trabajo suele ser constante. La intermediación de productores y consumidores de mensajes con una cola implica que la aplicación consumidora solo necesita la capacidad de administrar una carga promedio, en lugar de una carga de mucha actividad. La profundidad de la cola aumenta y se contrae a medida que varíe la carga entrante, lo que directamente ahorra dinero en función de la cantidad de infraestructura requerida para dar servicio a la carga de la aplicación. A medida que aumenta la carga, se pueden agregar más procesos de trabajo para que puedan leerse desde la cola. Cada mensaje se procesa únicamente por uno de los procesos de trabajo. Es más, este equilibrio de carga basado en la extracción permite el uso óptimo de los equipos de trabajo aunque estos equipos con capacidad de procesamiento extraigan mensajes a la frecuencia máxima. Este patrón con frecuencia se denomina patrón de consumo de competidor.

El uso de colas para intermediar entre los consumidores y productores de mensajes proporciona un acoplamiento no estricto inherente entre los componentes. Dado que los productores y consumidores no están relacionados entre sí, un consumidor puede actualizarse sin tener ningún efecto en el productor.

Creación de colas

Puede crear colas mediante una de las siguientes opciones:

A continuación, envíe y reciba mensajes mediante clientes escritos en lenguajes de programación, incluidos los siguientes:

Modos de recepción

Puede especificar dos modos diferentes en los que los consumidores pueden recibir mensajes de Service Bus.

  • Recepción y eliminación. En este modo, cuando Service Bus recibe la solicitud del consumidor, marca el mensaje como consumido y lo devuelve a la aplicación del consumidor. Este modo es el modelo más sencillo. Funciona mejor para los escenarios en los que la aplicación puede tolerar no procesar un mensaje en caso de error. Para entender este escenario, pongamos una situación en la que un consumidor emite la solicitud de recepción que se bloquea antes de procesarla. Cuando Service Bus marca el mensaje como consumido, la aplicación comienza a consumir mensajes al reiniciarse. Se omitirá el mensaje que se consumió antes del bloqueo. Este proceso se suele denominar procesamiento al menos una vez.
  • Inspección y bloqueo. En este modo, la operación de recepción se convierte en una operación de dos fases que hace posible admitir aplicaciones que no toleran la pérdida de mensajes.

    1. Busca el siguiente mensaje que se va a consumir, lo bloquea para impedir que otros consumidores lo reciban y, a continuación, lo devuelve a la aplicación.

    2. Una vez que la aplicación termina de procesar el mensaje, solicita al servicio Service Bus que complete la segunda fase del proceso de recepción. A continuación, el servicio marca el mensaje como consumido.

      Si la aplicación no puede procesar el mensaje por alguna razón, puede solicitar al servicio Service Bus que abandone el mensaje. Service Bus desbloquea el mensaje y hace que esté disponible para que el mismo consumidor u otro vuelvan a recibirlo. En segundo lugar, hay un tiempo de espera asociado con el bloqueo. Si la aplicación no puede procesar el mensaje antes de que finalice el tiempo de espera de bloqueo, Service Bus desbloquea el mensaje y hace que esté disponible para que pueda volver a recibirse.

      Si la aplicación se bloquea tras procesar el mensaje, pero antes de solicitar al servicio Service Bus que complete el mensaje, Service Bus volverá a entregar el mensaje a la aplicación cuando se reinicie. Este proceso se suele denominar procesamiento de al menos una vez. Es decir, cada mensaje se procesa al menos una vez. Sin embargo, en determinadas situaciones, es posible que se vuelva a entregar el mismo mensaje. Si el escenario no tolera el procesamiento duplicado, agregue lógica adicional en la aplicación para detectar duplicados. Para más información, consulte Detección de duplicados, que se conoce como procesamiento exactamente una vez.

      Nota

      Para más información acerca de estos dos modos, consulte Liquidación de las operaciones de recepción.

Temas y suscripciones

Una cola permite que un único consumidor procese un mensaje. En comparación con las colas, los temas y suscripciones proporcionan una vía de comunicación uno a varios en un patrón de publicación y suscripción. Resulta útil para escalar a un gran número de destinatarios. Cada mensaje publicado se pone a disposición de todas las suscripciones registradas en el tema. El publicador envía un mensaje a un tema y uno o varios suscriptores reciben una copia del mensaje.

Imagen que muestra un tema de Service Bus con tres suscripciones.

Las suscripciones pueden usar filtros adicionales para restringir los mensajes que desean recibir. Los publicadores envían mensajes a un tema de la misma manera en que envían mensajes a una cola. No obstante, los consumidores no reciben mensajes directamente del tema. En su lugar, los reciben de las suscripciones del tema. Una suscripción al tema se parece a una cola virtual en que recibe copias de los mensajes que se envían al tema. Los consumidores reciben los mensajes de una suscripción exactamente de la misma manera en que se reciben de una cola.

La funcionalidad de envío de mensajes de una cola los asigna directamente a un tema y su funcionalidad de recepción de mensajes a una suscripción. Entre otras cosas, esta característica significa que las suscripciones admiten los mismos patrones que se han descrito antes en esta sección con respecto a las colas: consumidor simultáneo, desacoplamiento temporal, nivelación de carga y equilibrio de carga.

Creación de temas y suscripciones

La creación de un tema es similar a la creación de una cola, como se describe en la sección anterior. Puede crear temas y suscripciones mediante una de las siguientes opciones:

A continuación, envíe mensajes a un tema y reciba mensajes de suscripciones mediante clientes escritos en lenguajes de programación como los siguientes:

Reglas y acciones

En muchos escenarios, los mensajes que tienen características específicas deben procesarse de maneras diferentes. Para permitir este procesamiento, puede configurar suscripciones para buscar los mensajes que tengan las propiedades deseadas y, después, realizar determinadas modificaciones en dichas propiedades. Mientras que las suscripciones del Service Bus ven todos los mensajes enviados al tema, solo se puede copiar un subconjunto de esos mensajes en la cola de suscripción virtual. Este filtrado se consigue mediante los filtros de suscripción. Dichas modificaciones se denominan acciones de filtrado. Cuando se cree una suscripción, podrá proporcionar una expresión de filtro que opere en las propiedades del mensaje. Las propiedades pueden ser del sistema (por ejemplo, etiqueta) y propiedades de la aplicación personalizadas (por ejemplo, StoreName). En este caso, la expresión de filtro SQL es opcional. Sin una expresión de filtro SQL, todas las acciones de filtro definidas en una suscripción se realizarán en todos los mensajes de dicha suscripción.

Para obtener un ejemplo práctico completo, vea el ejemplo TopicFilters en GitHub. Para más información acerca de los filtros, consulte Filtros y acciones de temas.

Entidades de Java Message Service (JMS) 2.0

Se puede acceder a las siguientes entidades a través de la API de Java Message Service (JMS) 2.0.

  • Colas temporales
  • Temas temporales
  • Suscripciones duraderas compartidas
  • Suscripciones duraderas no compartidas
  • Suscripciones no duraderas compartidas
  • Suscripciones no duraderas no compartidas

Obtenga más información sobre las entidades de JMS 2.0 y sobre cómo usarlas.

Pasos siguientes

Pruebe los ejemplos en el lenguaje que prefiera para explorar las características de Azure Service Bus.

A continuación, encontrará ejemplos de las bibliotecas cliente de .NET y Java anteriores: