Colas, temas y suscripciones de Service Bus
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.
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, ya que los mensajes se almacenan de forma 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.
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.
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.
Las suscripciones pueden usar más filtros para restringir los mensajes que quieren 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 realizan 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.
Entidades exprés
Las entidades rápidas se crearon para escenarios con un alto rendimiento y una latencia reducida. Con las entidades rápidas, si se envía un mensaje a una cola o tema, no se almacena inmediatamente en el almacén de mensajes. En su lugar, el mensaje se almacena inicialmente en la memoria caché. Los mensajes que permanecen en la entidad se escriben en el almacén de mensajes después de un retraso, en cuyo momento se protegen frente a la pérdida debido a una interrupción.
En las entidades normales, cualquier operación en tiempo de ejecución (como Enviar, Completar, Abandonar, Procesar como correo devuelto) se conserva primero en el almacén y solo después de que esto se confirma al cliente como correcto. En las entidades rápidas, una operación en tiempo de ejecución se reconoce al cliente como correcta en primer lugar y solo se conserva de forma diferida en el almacén. Como resultado, en el caso de un reinicio de la máquina o cuando se produce un problema de hardware, es posible que algunas operaciones en tiempo de ejecución reconocidas no se conserven en absoluto. Esto significa que el cliente obtiene una menor latencia y un mayor rendimiento con entidades rápidas, a costa de la posible pérdida de datos o reenvío de mensajes.
Además, con el tiempo se han realizado muchas optimizaciones en Service Bus, lo que significa que las ventajas de rendimiento y latencia de las entidades rápidas son actualmente mínimas. Además, el nivel Premium de Service Bus no admite entidades rápidas. Debido a esto, actualmente no se recomienda usar esta característica.
Pasos siguientes
Pruebe los ejemplos en el idioma que prefiera:
- Ejemplos de la biblioteca cliente de Azure Service Bus para .NET (versión más reciente)
- Ejemplos de la biblioteca cliente de Azure Service Bus para Java (versión más reciente)
- Ejemplos de la biblioteca cliente de Azure Service Bus para Python
- Ejemplos de la biblioteca cliente de Azure Service Bus para JavaScript
- Ejemplos de la biblioteca cliente de Azure Service Bus para TypeScript
Para obtener ejemplos que usan las bibliotecas cliente de .NET y Java anteriores, use los vínculos siguientes:
- Ejemplos de la biblioteca cliente de Azure Service Bus para .NET (versión heredada)
- Ejemplos de la biblioteca cliente de Azure Service Bus para Java (versión heredada)
El 30 de septiembre de 2026, retiraremos las bibliotecas del SDK de Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus y com.microsoft.azure.servicebus, que no se ajustan a las directrices del SDK de Azure. También retiraremos el soporte del protocolo SBMP, por lo que ya no podrás usar este protocolo después del 30 de septiembre de 2026. Migre a las bibliotecas más recientes del SDK de Azure, que ofrecen actualizaciones de seguridad críticas y funcionalidades mejoradas, antes de esa fecha.
Aunque las bibliotecas anteriores todavía se pueden usar después del 30 de septiembre de 2026, ya no recibirán soporte técnico oficial ni actualizaciones de Microsoft. Para obtener más información, consulte el anuncio de retirada de soporte técnico.