2012-01-08 22 views
9

Si usted tiene un requisito complejo conjunto con muchos usuarios (servidores) & cómo será su infraestructura WebSocket (servidor [s]) se escala, especialmente con la difusión?WebSocket escalabilidad, la radiodifusión se refiere a

Por supuesto, la radiodifusión no es parte de ninguna especificación de websocket, pero está ahí incluso en ejemplos básicos de chat (a.k.a. hello world for websocket).

La solución del lado del cliente (que solicita nuevos datos) parece aún más escalable que la solución del lado del servidor (difusión) con baja latencia de websockets y naturaleza relativamente barata (sin encabezado http).

Editar:

bien, sólo piensan que desea reemplazar todo el código AJAX con implementaciones WebSocket que puede significar que tantas conexiones dentro de contextos tan diferentes. Esto agrega una enorme complejidad a su sistema si desea realizar un seguimiento de todos los escenarios posibles para la transmisión.

Bajos (red/hilo, etc.) sugerencias de implementación de nivel son también parte del problema no la solución, porque esto significa que hay que codificar un servidor especial a diferencia de los servidores HTTP general.

Por otra parte, la radiodifusión trae algún tipo de carácter de estado a la mesa que no puede escalar fácilmente. Piense en agregar más servidores y balanceo de carga.

Respuesta

15

Escala soluciones web en tiempo real puede ser un problema complejo pero que servicios como Pusher (para quién trabajo) han resuelto, y uno que hay más definitivamente soluciones definidas para self hosted realtime web solutions - la PubSub paradigm se entiende bien y se ha resuelto muchos veces y para resolver el problema debe haber algún estado (quién se está suscribiendo a qué). Este paradigma se usa para transmitir los tipos de escenarios de los que está hablando.

Broadcasting diagram

tecnologías web en tiempo real se han construido con grandes cantidades de conexiones simultáneas en cuenta muchos - a partir de cero. Si quisiera crear una solución escalable, lo más probable es que utilice un servidor web existente en tiempo real que admita WebSockets, del mismo modo que es muy poco probable que decida implementar su propio servidor HTTP, es poco probable que desee implementar su propio servidor. que admite WebSockets desde cero.

dedicados servidores web en tiempo real también permiten separar su lógica de la aplicación de su mecanismo de comunicación en tiempo real (separación de intereses). Es posible que su aplicación necesite mantener algún estado, pero la tecnología en tiempo real se ocupa de administrar suscripciones y conexiones.Cómo se logra la comunicación entre la aplicación y la tecnología web en tiempo real depende de usted, pero con frecuencia se utilizan colas de mensajes y específicamente redis es muy popular en este espacio.

El sondeo de HTTP puede ser conceptualmente más fácil de entender: puede mantener la apatridia y con cada solicitud de encuesta HTTP especifica exactamente lo que está buscando. Pero definitivamente significa que tendrá que comenzar a escalar mucho antes (agregando más recursos para manejar la carga).

WebSocket polling es algo que no he considerado antes y tampoco creo que lo haya sugerido antes; la idea de que el cliente debería decir "Estoy listo para mi próximo conjunto de datos y esto es lo que quiero" es interesante. WebSockets en general han dado un salto lejos del paradigma de solicitud/respuesta, pero puede haber escenarios en los que la mayor eficiencia de WebSockets y la solicitud/respuesta al usarlos pueda tener algunos beneficios. El marco de aplicación SocketStream puede valer la pena ya que podría ser relevante; después de la carga de la aplicación inicial, toda la comunicación se realiza a través de WebSockets, lo que significa que la funcionalidad de solicitud/respuesta básica del evento utiliza WebSockets.

SocketStream logo

Sin embargo, puesto que estamos hablando de datos de radiodifusión que necesitamos para volver al paradigma PubSub donde hace mucho más sentido tener suscripciones activas y cuando hay nuevos datos disponibles que los nuevos datos se distribuye a las suscripciones activas (presionadas). Toda su aplicación necesita saber si hay suscripciones activas o no para decidir si publicar o no los datos. Ese problema ha sido resuelto.

1

La idea de websockets es que mantenga una conexión constante con cada cliente. Cuando hay nuevos datos que desea enviar a cada cliente, ya sabe quiénes son todos los clientes, así que debe enviarlos.

Parece que desea que cada cliente envíe constantemente solicitudes al servidor para obtener nuevos datos. ¿Por qué? Parece que eso desperdiciará el ancho de banda de todos y no sé por qué crees que será más escalable. Tal vez podría agregar más detalles a su pregunta, como qué tipo de información está transmitiendo, con qué frecuencia, cuántos bytes, cuántos clientes, etc.

¿Por qué no considerar una conexión abierta de websocket como una solicitud permanente de el cliente para obtener más datos?

+2

En mi humilde opinión, "saber quiénes son todos los clientes" no es tan fácil en el lado del servidor del desarrollo de websocket. Debe hacer un seguimiento de todos en su contexto de manera eficiente y también tener más de un servidor lo hace más complejo. IMO, solicitar nuevos datos es más escalable porque la implementación de su servidor no tiene que conocer a los clientes para que pueda agregar fácilmente nuevos servidores. Y una vez más, no es realmente una pérdida de ancho de banda si lo mantienes pequeño y puedes hacerlo con un websocket http sin cabeza. –

+1

No importa lo que haga, el servidor debe conocer a los clientes porque debe mantener una lista de los sockets abiertos. Sin una lista de sockets abiertos, no podrá escuchar los datos entrantes de ellos (por ejemplo, no sabrá qué lista de descriptores de archivos pasar a las funciones 'select' o' epoll'). También necesita hacer un seguimiento de un búfer para los datos entrantes y salientes, creo. No puede olvidarse de las conexiones abiertas de TCP/IP. Como de todos modos está haciendo un seguimiento de esa lista, no debería ser demasiado difícil agregar algunos de sus propios datos de identificación a esa lista, si es necesario. –

+0

Estás a punto de mezclar conceptos de sesión y socket; el primero es el nivel de la aplicación y el segundo es el nivel de la red como usted sabe. En la práctica, no quieres ir tan profundo, yo tampoco. En mi humilde opinión, es mejor pensar este problema en el nivel de aplicación. –

Cuestiones relacionadas