event handling - ¿Debo usar conexiones separadas para Pub y Sub con Redis?
event-handling message-queue (1)
Me he dado cuenta de que Socket.io está utilizando dos conexiones separadas para Pub y Sub al servidor Redis . ¿Es algo que podría mejorar el rendimiento? ¿O se trata simplemente de un movimiento hacia controladores de eventos y códigos más organizados? ¿Cuáles son los beneficios y desventajas de las dos conexiones separadas y una sola conexión para publicar y suscribirse?
PD El sistema está presionando aproximadamente la misma cantidad de mensajes que está recibiendo. Impulsa las actualizaciones a los servidores, que están en el mismo nivel en la jerarquía, por lo que no hay ningún maestro, empujando todas las actualizaciones, o esclavo, consumiendo los mensajes. Un servidor tendría entre 4 y 8 suscripciones y enviará los mensajes a estos servidores.
PSS ¿Es esto más un trabajo para una cola de trabajos especialmente diseñada? La razón por la que estoy mirando a Redis. es que ya tengo algunos objetos compartidos en él, que todos los servidores usan. ¿Vale la pena agregar otra conexión de red a la cola de mensajes?
Debes usar dos conexiones para pub y sub. Una conexión de suscriptor no puede emitir ningún comando que no sea subscribe , psubscribe , unsubscribe , punsubscribe (aunque @Antirez ha insinuado un ping seguro para suscriptores en el futuro). Si intentas hacer otra cosa, redis te dice:
-ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / QUIT allowed in this context
(tenga en cuenta que no puede probar esto con redis-cli, ya que entiende el protocolo lo suficientemente bien como para evitar que emita comandos una vez que se haya suscrito, pero cualquier otra herramienta básica de socket debería funcionar bien)
Esto se debe a que las conexiones de los suscriptores funcionan de manera muy diferente: en lugar de trabajar en base a una solicitud / respuesta, los mensajes entrantes ahora pueden aparecer en cualquier momento, sin ser solicitados.
publish es un comando de solicitud / respuesta regular, por lo que debe enviarse en una conexión normal, no en una conexión de suscriptor.