¿MQTT es escalable con más de 1000 clientes?

10

Escenario
Dispositivo IoT (actualmente dispositivo IPv4) que envía a través del socket TCP una carga útil a un servidor una vez al día. El servidor tiene una dirección IP pública, el dispositivo está detrás de un enrutador / NAT. Voy a usar un módulo basado en ESP8266 (es decir, Olimex uno)

Objetivo
El servidor debe poder enviar datos a cualquier cliente cuando sea necesario. No estoy interesado en la comunicación directa de cliente a cliente (es decir, conectarme a un dispositivo desde mi teléfono inteligente) como se supone que debe hacer la perforación.

Otros requisitos
Los dispositivos IoT pueden crecer hasta varios miles. Su conexión a Internet es proporcionada por muchos enrutadores / módems con capacidad 4G. Cada uno manejará 10-20 clientes.

Solución propuesta
Hasta donde yo entiendo, una solución común es MQTT. Los clientes envían periódicamente datos al agente (es decir, Mosquitto que se ejecuta en el servidor de alojamiento), que a su vez actualiza la aplicación web principal que se ejecuta en el mismo servidor.

Pregunta
¿El enfoque MQTT es adecuado para un "gran" número de dispositivos (más de 1000) la mayoría de ellos detrás de un enrutador 4G?

marca
fuente
Puede ser mejor hacer la pregunta (1) por separado y solo hacer la pregunta (2) que coincida con su título en el cuerpo de la pregunta. De esta manera, podemos abordar cada una de sus preguntas por separado en detalle. Puede incluir su contexto nuevamente en la nueva pregunta o vincular a esta si le resulta útil.
Aurora0001
1
La pregunta cambió y agregó la segunda.
Mark
Por lo que parece, incluso si se encontrara con problemas de carga del servidor al mantener un gran número de conexiones abiertas, su sistema sería bastante compatible con un tipo de topología de árbol donde los clientes se conectan a servidores intermedios que mantienen las sesiones correspondientes y pasan el tráfico infrecuente hacia arriba y hacia abajo a servidores superiores en una sola tubería cada uno. Probablemente incluso podría hacer el primer nivel de esto localmente en sus enrutadores 4G.
Chris Stratton

Respuestas:

7

1,000 clientes pueden ser manejados fácilmente por cualquier agente decente de MQTT; hay un punto de referencia de Scalagent que muestra que una PC con:

  • un procesador Intel Core 2 Duo de 3 GHz
  • 4 GB de RAM

podría manejar a 60,000 editores con Mosquitto. Esto es muy superior a los 1,000 publicadores requeridos, por lo que incluso en un servidor relativamente débil, aún debería poder manejar el número requerido.

Algunos otros corredores afirman un rendimiento aún mejor (con una potencia de servidor correspondientemente mayor, por supuesto), como HiveMQ , que afirmó manejar 10 millones de editores.

Los corredores MQTT generalmente esperan una conexión persistente, y agotarán el tiempo de espera de los clientes que no envían respuestas de ping (u otra actividad) periódicamente. Puede desconectarse de la red después de la publicación, pero, obviamente, no podrá recibir nada si se desconecta.

MQTT admite el concepto de mensajes 'retenidos' que podrían ser útiles. El cliente web puede publicar algo en un tema con el indicador retenido, y el intermediario almacenará este mensaje. Cada vez que sus clientes se vuelvan a conectar y se suscriban al tema, recibirán el mensaje retenido (incluso si fue publicado hace horas). El mensaje retenido se publica cada vez que un cliente se suscribe a ese tema, por lo que podría ayudarlo si tiene una conexión irregular y necesita que se almacene un mensaje hasta que el cliente se vuelva a conectar.

Aurora0001
fuente
Seguramente lo expliqué mal. Solo el servidor (servicio de alojamiento comercial) debe manejar los más de 1000 clientes. Hay muchos enrutadores 4G en diferentes lugares, y cada uno manejará solo 10-20 clientes.
Mark
Oh, leí mal: mi culpa, @ Mark, supuse que se refería a todos ellos detrás de un enrutador 4G. Editaré esto en ese caso.
Aurora0001
Todavía no entiendo completamente el código subyacente de MQTT: tenía miedo de las conexiones 4G: ¿el MQTT requiere conexiones de Internet persistentes? Probablemente la red será inestable ...
Mark
He editado con algunas sugerencias, @Mark; déjame saber si eso te señala en la dirección correcta.
Aurora0001
1
Sí, ahora está más claro. Voy a hacer algunas búsquedas adicionales sobre este tema y si todavía necesito ayuda, haré otra pregunta. Muchas gracias.
Mark
5

Puede usar sesiones persistentes de los clientes, por ejemplo, el indicador limpio establecido en falso al conectarse. En ese caso, cuando su cliente está fuera de línea, el agente lo almacenará en su propia memoria caché y lo entregará una vez que el dispositivo se conecte.

Sobre la cantidad: 10K es una cantidad relativamente baja incluso para un servidor. Puede configurar el servidor Linux para mantener 500K conexiones activas y si su agente estará basado en la nube, por ejemplo, proporcionado como servicio por algún proveedor, puede mantener incluso millones de conexiones activas.

Por cierto, creo que Mosquitto o cualquier otra instalación local es la opción perfecta para el desarrollo y las pruebas, pero cuando entre en producción necesita el agente SaaS MQTT con todas las características como HA, redundancia, conmutación por error, etc.

shal
fuente
No creo que un corredor SaaS MQTT sea siempre el mejor para la producción. La mayoría de los corredores MQTT profesionales (autohospedados) admiten HA, redundancia y conmutación por error a escala mientras mantienen la compatibilidad total con MQTT. Algunos corredores de SaaS no admiten todas las funciones de MQTT. Si prueba contra un mosquitto local y luego acude a un proveedor de SaaS, es probable que las cosas no funcionen en la producción como se esperaba.
Dominik Obermaier
Como de costumbre, hay ventajas y desventajas de ambas opciones. Obviamente, cualquier corredor de SaaS requiere un equipo comunicativo perfecto, pruebas a largo plazo en la etapa inicial del desarrollo del producto, garantías claras de tiempo de actividad y varios SLA. Mantener un corredor propio también es una buena manera, pero el mundo se está moviendo hacia los servicios. O bien, se esforzará y será más competente con su producto que utiliza el agente como parte de él, o bien, gastará tiempo y dinero en ser un administrador de agente de MQTT súper experimentado (¡y nunca será su desarrollador!). Solo es una cuestión de elección +)
shal