socket.io sobre varios servidores sin redis

los puntos finales de mi api están distribuidos en varios servidores en varias ubicaciones y estoy tratando de averiguar cómo lidiar con las actualizaciones de socket en los clientes conectados. Realmente me gustaría evitar tener una única configuración de db redis solo para manejar los clientes conectados a través de los muchos servidores.

No tendré que transmitir mensajes, los mensajes de socket siempre se enviarán a un solo usuario. aunque conozco cada ID de canal de los clientes conectados, no estoy seguro de si es posible emitir un mensaje a un solo usuario cuando tengo la ID del canal en mis manos y, por ejemplo, la conexión inicial se realizó con otro servidor en uno de los clústeres .

Veo que hay una opción para el balanceo de carga, pero no estoy completamente seguro de que eso sea lo que realmente necesito.

Gracias a todos los que pudieron darme una explicación más detallada de cuál es la mejor manera de hacerlo.

No está claro exactamente lo que estás preguntando. Cuando tiene usuarios conectados a una variedad de servidores y desea enviar un mensaje de un servidor a un usuario en particular, finalmente debe entregar ese mensaje al servidor al que está conectado el usuario para que pueda enviar el mensaje a través del usuario. conexión.

Hay una variedad de maneras de hacer eso:

  1. Base de datos central. Mantenga una base de datos central que le indique a qué servidor está conectado un usuario en un momento dado. Luego, cuando desee enviar un mensaje al usuario A, puede buscarlos en la base de datos central y encontrar que actualmente están conectados a Server12 y luego puede pedirle a Server12 que les envíe el mensaje. Esta es la estrategia que utiliza la solución socket.io redis. Esta estrategia puede crear un cuello de botella en la base de datos central ya que todos los servidores deben usar la misma base de datos central para “buscar” cuando un usuario determinado está conectado.

  2. Algoritmo de equilibrio de carga . Cree un algoritmo de equilibrio de carga que calcule a qué servidor se conectará un usuario determinado en función de su ID de usuario (a menudo utilizando un hash de la ID de usuario que luego se divide equitativamente entre la cantidad de servidores actualmente activos). En este esquema, cuando un usuario se conecta, se equilibran la carga de un servidor elegido algorítmicamente. Entonces, el usuario A siempre se enviaría a Server12, por ejemplo. Luego, en otra parte de la granja de servidores, si desea enviar un mensaje al usuario A, puede usar el mismo algoritmo para calcular a qué servidor se conectarán y puede contactar a ese servidor para pedirle que les envíe el mensaje. Este esquema puede tener dificultades cuando desea cambiar el número de servidores activos porque eso causa un cambio en el algoritmo de equilibrio de carga que requiere que todos los usuarios existentes se vuelvan a conectar a través del nuevo algoritmo para que su conexión sea predecible nuevamente.

  3. Transmisión de mensajes salientes a todos los servidores. Difundir mensajes salientes para un usuario en particular a todos los servidores. En este caso, si Server10 desea enviar un mensaje al usuario A, primero verifica si ya tiene una conexión para el usuarioA. Si lo hace, simplemente envía el mensaje. Si no lo hace, entonces simplemente difunde a todos los demás servidores activos que desea enviar este mensaje en particular a UserA. Cada servidor verificará su lista de conexiones y, si tiene una conexión para UserA, enviará el mensaje a UserA. Este método no se adapta bien al alto tráfico (por ejemplo, situaciones con muchos mensajes porque todos los servidores reciben todos los mensajes salientes), pero puede escalar bien para muchos usuarios, pero con poco tráfico.

  4. Cada servidor mantiene su propio índice de conexión, difunde conexiones entrantes y se desconecta a todos los servidores. En este esquema, cada servidor mantiene un índice en memoria para cualquier usuario conectado. Cada vez que un usuario se conecta a un servidor en particular, ese servidor luego transmite a todos los demás servidores que el Usuario A está ahora conectado a Server12. Cada vez que el Usuario A se desconecta, la desconexión también se transmite. Cada servidor actualiza su índice en memoria en cada uno de estos eventos, por lo que en cualquier momento dado, cada servidor tiene una tabla de búsqueda en vivo donde cada usuario está conectado actualmente. Este método no se escala tan bien para un gran número de usuarios porque cada servidor tiene la tarea de mantener un índice en la memoria de todas las conexiones activas y cada servidor recibe un mensaje cuando cualquier usuario se conecta o desconecta. Sin embargo, funciona bien para un tráfico elevado porque cada servidor ya tiene una forma rápida de saber dónde está conectado un usuario determinado.

Dependiendo de las características de carga particulares de una situación dada para la que intenta optimizar, uno puede combinar aspectos de cada uno de estos métodos en soluciones híbridas también. Por ejemplo, las conexiones y las desconexiones pueden transmitirse a N servidores de bases de datos especializados y los servidores individuales pueden distribuir su carga a través de esos N servidores de bases de datos cuando buscan un usuario determinado para aliviar la base de datos central, lo que representa un cuello de botella.

    Intereting Posts