architecture - zmq vs redis para pub-sub patrón

zeromq publish-subscribe

Question

redis soporta pub-sub
zmq también es compatible con pub-sub a través de un intermediario de mensajes

¿Cuáles serían las ventajas arquitectónicas para elegir entre ellos?
Estoy apuntando a puntos que están más allá del obvio caso de uso que se debe realizar una evaluación comparativa del rendimiento (aquí hay un buen ejemplo ).

Supongamos el uso de un lenguaje de alto nivel como Python.

Answer 1

Así es como lo decidiría yo. Hacer casos de prueba mínimos con cada producto. Vea cuál es más fácil de construir y funciona mejor. Empuje cada caso de prueba un poco más y luego deseche una línea como demasiado trabajo.

Answer 2

He estado investigando esto por mí mismo, ya que necesitaba decidir si usar Redis pubsub o ZMQ pubsub para la capa de comunicación para sistemas distribuidos. Creo que Redis y ZMQ difieren en cuanto a cómo se configura la aplicación.

1. ZMQ pubsub innatamente se conectan directamente, es decir, no hay intermediarios.
   Puede crear una instancia similar a un intermediario, como un dispositivo reenviador

2. Para Redis pubsub, tanto el suscriptor como el editor necesitan conectarse a Redis.

La falta de intermediarios en ZMQ significa que el suscriptor necesita saber de alguna manera conectarse con el editor para recibir el mensaje. En mi sistema donde la aplicación genera editores que necesitan enviar información a los suscriptores, no hay forma de hacerlo sin tener un dispositivo reenviador al que se conecten los suscriptores antes de que se inicie mi aplicación.

La latencia importa en mi sistema, ya que quiero que las cajas remotas hagan las cosas tan rápido como sea posible.

Zmq (direct pubsub)
avg: 0.000235867897669
max: 0.0337719917297
min: 0.000141143798828

Zmq (w/ forwarder)
Avg: 0.00237249334653
max: 0.00536799430847
min: 0.000249862670898

Redis (8gb ram)
avg: 0.000687216520309
max: 0.0483138561249
min: 0.000313997268677

Redis (32gb ram)
avg: 0.000272458394368
max: 0.00277805328369
min: 0.000216960906982

• Si su aplicación está en el lado del suscriptor donde hay un demonio de editor del que desea obtener información, entonces me gustaría ir a ZMQ porque puede conectarse directamente al editor.
• si su aplicación está en el lado del editor, entonces iría a Redis pubsub porque los suscriptores ya están conectados a Redis escuchando.

Answer 3

He trabajado tanto con ZeroMQ como con Redis con python. Yo diría que ZeroMQ es más robusto, ofrece un equilibrio de carga simple y real, y también más que un pub-sub, como una respuesta de solicitud entre otros. Pero si solo buscas pub-sub, redis es mucho más simple.

En caso de que el servidor redis se bloquee o deje de funcionar, todos los clientes también dejarán de funcionar, con ZeroMQ, los clientes funcionarán incluso si no hay un servidor.

Ambos servicios están disponibles con cualquier lenguaje de programación, ruby, python, C, C ++ y más.

En resumen, redis es mucho más simple, muy confiable. ZeroMQ es extremadamente confiable pero más complejo.

Si solo estuviera haciendo pub sub, escogería redis, de lo contrario escogería ZeroMQ. Si quisiera ver grandes cargas de tráfico, elegiría ZeroMQ

Answer 4

ZeroMq Pros / Contras

• Pub / sub pares pueden conectarse y desconectarse de forma independiente; los mensajes se guardan en buffers según la configuración de HWM, se envían automáticamente según la disponibilidad de los pares (almacenar y reenviar)
• Si un par falla, se perderán los mensajes almacenados.
• Las suscripciones de temas admiten la coincidencia de prefijos con pub / sub envolvente solamente; NEWS suscripción a NEWS coincide con los mensajes de NEWS*

Redis Pros / Cons

• AOF toma instantáneas en el disco y los mensajes persisten en caso de que la redis falla.
• Pub / Sub clientes dependen de redis para la conectividad
• Coincidencia de comodines para suscripciones de temas selectivos como news.* Admitido