cli - Redis Cluster vs ZeroMQ en Pub/Sub, para sistemas distribuidos de escala horizontal
redis op (2)
Si tuviera que diseñar un gran sistema distribuido cuyo rendimiento debería escalar linealmente con el número de suscriptores y el número de canales en el sistema, ¿cuál sería mejor?
1) Redis Cluster (solo para Redis 3.0 alpha, si está en modo clúster, puede publicar en un nodo y suscribirse en otro nodo completamente diferente, y los mensajes se propagarán y llegarán a usted). La complejidad de la publicación es O (N + M) , donde N es el número de clientes suscritos y M es el número de patrones suscritos en el sistema, pero ¿cómo se escala cuando está en un grupo Redis? Acepto conjeturas educadas sobre esto.
2) ZeroMQ desde la versión 3.x, realiza el filtrado del lado del servidor, por lo que también tiene cierta complejidad de tiempo allí, pero no he visto nada al respecto en la documentación. Si quisiera escalarlo, podría tener muchos servidores publicando en cualquier canal, y cada suscriptor se conectaría a todos los servidores y se suscribiría al canal deseado. Eso me parece bien.
Entonces, ¿cuál de ellos es mejor para la escala horizontal de un gran sistema de publicación? ¿Cuáles son otras soluciones que debería considerar? Recuerde, quiero minimizar la latencia y el rendimiento, pero poder escalar horizontalmente.
En Redis, como en ZeroMQ, el cuello de botella será la red. Redis puede llegar a millones de mensajes por segundo, al menos tanto o más que ZeroMQ.
Debe tener en cuenta que la implementación actual de Redis Cluster distribuye los mensajes PUBLICADOS en todos los nodos del clúster utilizando el bus internodo. Este enfoque supone que PUBLISH es extremadamente barato en Redis (como se explica en este problema en Github ).
Sin embargo, hay una pequeña sobrecarga involucrada que es la comunicación entre nodos. A medida que se amplíe esta sobrecarga será más importante. Hay otra implementación de Redis Cluster que conozco (por favor, tenga en cuenta que es comercial), en la que los canales o patrones se distribuyen entre los nodos del clúster de manera similar a la forma en que se distribuyen las teclas Redis. Al menos según el proveedor, esto debería ahorrar la sobrecarga de la comunicación entre nodos y aumentar el rendimiento, pero no lo he evaluado yo mismo.
Quieres minimizar la latencia, supongo. El número de canales es irrelevante. Los factores clave son la cantidad de publicadores y la cantidad de suscriptores, el tamaño del mensaje, la cantidad de mensajes por segundo por publicador, la cantidad de mensajes recibidos por cada suscriptor, aproximadamente. ZeroMQ puede hacer varios millones de mensajes pequeños por segundo de un nodo a otro; su cuello de botella será la red mucho antes de que sea el software. Por lo tanto, la mayoría de las arquitecturas de pubsub de alto volumen usan algo como PGM multicast, que ZeroMQ soporta.