¿Qué es una suscripción compartida de MQTT?
La entrega ordinaria de MQTT es una difusión: cada suscriptor a un tópico recibe cada mensaje coincidente. Eso es exactamente lo que se quiere para tableros y pantallas, pero es el modelo equivocado cuando un solo servicio ya no puede seguirle el paso a un flujo de telemetría de alto volumen y se necesitan varias copias de ese servicio para repartir la carga. Una suscripción compartida resuelve esto. Varios consumidores se unen a un grupo nombrado, y el broker entrega cada mensaje a un solo miembro del grupo en lugar de a todos. Esta guía explica la sintaxis $share, cómo distribuye los mensajes el broker, y por qué las suscripciones compartidas importan al escalar la capa de ingesta de un sistema SCADA en la nube.
Suscripcion compartida de MQTT en una línea: Una suscripción compartida de MQTT permite que varios clientes formen un grupo nombrado que se suscribe en conjunto a un tópico, y el broker entrega cada mensaje coincidente a un solo miembro del grupo en lugar de a todos. Convierte la difusión por defecto de MQTT en balanceo de carga, de modo que un flujo de telemetría exigente pueda repartirse entre varios servidores consumidores que cada uno procesa una parte de los mensajes.
De la difusión al balanceo de carga
Por defecto MQTT es un sistema de publicación y suscripción en el sentido más puro, lo que significa que cada cliente suscrito a un tópico coincidente recibe su propia copia de cada mensaje. Dos pantallas de operador que vigilan el mismo pozo ven ambas cada lectura, y ese es el comportamiento que hace tan conveniente a MQTT para el monitoreo. El problema aparece del lado del procesamiento. Si un servidor se suscribe a una manguera de telemetría y no puede con la tasa, agregar un segundo servidor de la forma ordinaria no ayuda, porque el segundo servidor simplemente recibe los mismos mensajes que el primero y ambos se rezagan juntos.
Una suscripción compartida cambia la regla de entrega para un conjunto definido de consumidores. En lugar de que cada suscriptor reciba cada mensaje, los miembros de un grupo compartido reciben el flujo colectivamente exactamente una vez, y el broker elige a un miembro del grupo para entregarle cada mensaje individual. Agregar otro consumidor al grupo ahora sí reduce la carga de los demás, porque el broker reparte los mensajes entre todos los miembros disponibles. Es la misma idea que un grupo de consumidores en una cola de mensajes, traída a MQTT.
La suscripción se identifica por un nombre compartido para que el broker sepa qué clientes van juntos. El resto de MQTT no cambia: los publicadores no necesitan saber que existe una suscripción compartida, publican hacia el tópico exactamente como antes, y el broker se encarga de elegir un destinatario por mensaje entre el grupo. Un sistema incluso puede mezclar modelos, con un grupo compartido de trabajadores balanceando la ingesta mientras suscriptores ordinarios separados siguen recibiendo la difusión completa para la visualización en vivo.
El prefijo $share y la sintaxis de grupo
Las suscripciones compartidas se solicitan mediante un prefijo especial de filtro de tópico. Un cliente se suscribe a un filtro de la forma $share seguido de un nombre de grupo y luego el filtro de tópico real, de modo que un grupo llamado ingest suscribiéndose a un tópico de telemetría de sitio usa un filtro que empieza con $share/ingest/ y continúa con el patrón de tópico normal incluyendo cualquier comodín. Cada cliente que se suscribe con el mismo nombre de grupo y el mismo filtro de tópico se une al mismo grupo de balanceo de carga, y el broker los trata como destinatarios intercambiables.
El nombre de grupo es arbitrario y lo elige el diseñador del sistema, y nombres de grupo distintos crean grupos independientes. Esa independencia es útil: un flujo puede alimentar tanto un grupo ingest que escribe al historiador como un grupo alarms separado que evalúa condiciones, y cada grupo recibe su propia copia completa del flujo mientras balancea internamente entre sus propios miembros. Dentro de un grupo, el broker distribuye los mensajes por algún esquema de su elección, comúnmente un enfoque round-robin o de menor carga, y la política exacta varía entre implementaciones de broker.
Hay detalles prácticos que conviene respetar. El orden de los mensajes a través del grupo no es el mismo que el orden en una sola conexión, porque mensajes consecutivos pueden ir a miembros distintos, así que los consumidores no deben suponer que ven una porción estrictamente ordenada del flujo. La calidad de servicio y el reconocimiento siguen aplicando por entrega, así que un mensaje entregado a un miembro que no lo reconoce puede reentregarse, y un consumidor bien diseñado mantiene idempotente su procesamiento por mensaje para que una reentrega no haga daño.
Escalar la ingesta del SCADA en la nube
En una plataforma SCADA en la nube la capa de ingesta es donde primero aparece la presión de escala. La telemetría de una gran flota de pozos, tanques y compresores converge en el broker, y los servicios que decodifican cargas útiles, las validan y las escriben al historiador deben seguir el paso de la tasa combinada de cada sitio. Un solo proceso de ingesta es un cuello de botella y un único punto de falla. Una suscripción compartida permite a la plataforma correr un grupo de trabajadores de ingesta idénticos que consumen el flujo en conjunto, de modo que el rendimiento escala agregando trabajadores en lugar de hacer cada vez más veloz a un solo trabajador.
Este modelo también mejora la resiliencia durante la operación. Si un trabajador del grupo colapsa o se retira para un despliegue, el broker simplemente deja de enviarle mensajes y sigue distribuyendo entre los sobrevivientes, y el flujo sigue corriendo sin un hueco. Cuando el trabajador regresa, o se arranca uno nuevo para manejar un crecimiento de dispositivos de campo, se une al grupo y de inmediato comienza a tomar una parte. El equipo de operaciones puede crecer y encoger el grupo de ingesta para igualar la cantidad de sitios reportando sin cambiar nada en el borde ni reconfigurar publicadores.
Para una plataforma como Merobix que ingiere de muchos sitios remotos, las suscripciones compartidas encajan de forma natural con las partes del canal que son pura distribución de trabajo, como analizar y almacenar lecturas, mientras las suscripciones ordinarias siguen siendo la opción correcta para cualquier cosa que necesite cada mensaje, como un mapa en vivo o un anunciador de alarmas. La distinción es entre trabajo que debe hacerse una vez por mensaje e información que debe llegar a cada visualizador interesado. Las suscripciones compartidas dan lo primero sin perturbar lo segundo.
Preguntas frecuentes
¿En qué se diferencia una suscripción compartida de una suscripción normal?
Una suscripción MQTT normal entrega cada mensaje coincidente a cada suscriptor, lo cual es una difusión. Una suscripción compartida agrupa a varios clientes bajo un nombre compartido y entrega cada mensaje a un solo miembro de ese grupo, lo cual es balanceo de carga. Se usa una suscripción normal cuando todos necesitan los datos y una compartida cuando se quiere repartir el procesamiento entre varios servidores.
¿Qué les pasa a los mensajes si un miembro del grupo se desconecta?
Cuando un miembro de un grupo compartido se desconecta, el broker deja de seleccionarlo y distribuye los mensajes entre los miembros restantes, así que el flujo continúa sin ese consumidor. Cualquier mensaje que se le había entregado pero no reconocido puede reentregarse a otro miembro según el nivel de calidad de servicio. Por eso los consumidores de reparto de carga suelen escribirse para procesar mensajes de forma idempotente, de modo que una reentrega ocasional no haga daño.
¿El publicador tiene que hacer algo especial?
No. Los publicadores desconocen por completo las suscripciones compartidas. Publican hacia el tópico ordinario exactamente como siempre lo harían, y el broker decide si difunde un mensaje a los suscriptores normales, lo balancea entre un grupo compartido, o ambos. Toda la lógica de suscripción compartida vive del lado del suscriptor mediante el prefijo de filtro de tópico $share.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.