Estamos usando socket i/o para muchos datos en vivo. El usuario envía/recibe los datos usando sockets. Como usamos el equilibrador de carga, no podemos usar el modelo de espacio de nombres de socket i/o y, en su lugar, usar el pub/sub de redis dentro del socket.
Hasta ahora, estábamos creando una conexión redis separada para la suscripción por usuario por canal. Pero recientemente nos enfrentamos a un problema de conexión máxima alcanzada ( Error: Ready check failed: ERR max number of clients reached ) en redis y nos dimos cuenta de que se debe a que había demasiadas conexiones redis a través de pub sub.
Para contrarrestar eso, se me ocurrió que, en lugar de usar varias conexiones Redis de suscripción por usuario, ¿por qué no tener una conexión Redis de publicación y una conexión Redis de suscripción que escuchará todos los canales y se puede lograr de la siguiente manera:
var pub = redis.createClient(); var sub = redis.createClient(); sub.psubscribe('*'); sub escuchará todos los canales. Además, podemos almacenar información sobre los canales a los que el usuario está suscrito en el objeto socket y manejar los datos en consecuencia.
Con suerte, soy claro con la declaración del problema y me gustaría entender cómo será el rendimiento con este patrón de diseño.
En cuanto al rendimiento, es mucho mejor usar una sola conexión, es mucho menos estresante para el servidor redis y, al publicar datos, no tendrá que recorrer todas las conexiones. El "patrón" crea algunos gastos generales, pero es muy insignificante, asegúrese de ser más específico acerca de sus patrones, es posible que publique otro evento en ese servidor en el futuro.
sub.psubscribe('someprefix_*');Por cierto, si su problema es transmitir a socket.io dentro del contexto de varias instancias de NodeJS, puede consultar este módulo: https://github.com/socketio/socket.io-redis
Aprovecha redis para proporcionar una experiencia escalable de múltiples nodos con socket.io