Cola de mensajes de baja latencia y a gran escala

Question

Estoy pasando un poco de repensación de juegos multijugador a gran escala en la era de las aplicaciones de Facebook y la computación en la nube.

Supongamos que debía construir algo sobre los protocolos abiertos existentes, y quiero servir a 1,000,000 de jugadores simultáneos, solo para alcanzar el problema.

Supongamos que cada jugador tiene una cola de mensajes entrante (para chat y demás), y en promedio una cola de mensajes entrantes más (gremios, zonas, instancias, subasta, ...) para que tengamos 2,000,000 de colas. Un jugador escuchará 1-10 colas a la vez. Cada cola tendrá en promedio tal vez 1 mensaje por segundo, pero ciertas colas tendrán una tasa mucho más alta y un mayor número de oyentes (digamos, una cola de "ubicación de entidad" para una instancia de nivel). Supongamos que no más de 100 milisegundos de latencia de cola de sistemas, que está bien para juegos ligeramente orientados a la acción (pero no juegos como Quake o Unreal Tournament).

De otros sistemas, sé que servir a 10,000 usuarios en una sola caja de 1U o Blade es una expectativa razonable (suponiendo que no hay nada más costoso, como la simulación de física o otras cosas).

Entonces, con un sistema de clúster de barra cruzada, donde los clientes se conectan a las puertas de enlace de conexión, que a su vez se conectan a los servidores de cola de mensajes, obtendríamos 10,000 usuarios por puerta de enlace con 100 máquinas de puerta de enlace y 20,000 colas de mensajes por servidor de colas con 100 máquinas de colas. De nuevo, solo para el alcance general. El número de conexiones en cada máquina MQ sería pequeño: alrededor de 100, para hablar con cada una de las puertas de enlace. El número de conexiones en las puertas de enlace sería mucho más alta: 10,100 para los clientes + conexiones a todos los servidores de cola. (Además de esto, agregue algunas conexiones para los servidores de simulación del mundo del juego o otras cosas, pero estoy tratando de mantener eso separado por ahora)

Si no quisiera construir esto desde cero, tendría que usar algunos mensajes y/o infraestructura de cola que exista. Los dos protocolos abiertos que puedo encontrar son AMQP y XMPP. El uso previsto de XMPP es un poco más como lo que necesitaría este sistema de juego, pero la sobrecarga es bastante notable (XML, más los datos de presencia detallada, además de otros canales que deben construirse en la parte superior). El modelo de datos real de AMQP está más cerca de lo que describo anteriormente, pero todos los usuarios parecen ser grandes corporaciones de tipo empresarial, y las cargas de trabajo parecen estar relacionadas con el flujo de trabajo, no relacionadas con la actualización del juego en tiempo real.

¿Alguien tiene alguna experiencia diurna con estas tecnologías, o implementaciones de las mismas, que puede compartir?

Answer 1

@Msalters

Re 'cola de mensajes':

La operación predeterminada de RabbitMQ es exactamente lo que usted describe: transitorio de pubsub. Pero con TCP en lugar de UDP.

Si desea una entrega eventual garantizada y otras funciones de persistencia y recuperación, entonces también puede tener eso, es una opción. Ese es el objetivo de RabbitMQ y AMQP: puede tener muchos comportamientos con solo un sistema de entrega de mensajes.

El modelo que describe es el comportamiento predeterminado, que es transitorio, "fuego y olvida", y enrutando mensajes a donde sea que estén los destinatarios. Las personas usan RabbitMQ para hacer descubrimiento de multidifusión en EC2 por esa razón. Puede obtener comportamientos de tipo UDP sobre unicast TCP PubSub. Ordenado, ¿eh?

Re UDP:

No estoy seguro de si UDP sería útil aquí. Si apaga a Nagling, se ha medido con RabbitMQ Mensaje único Roundtrip Latency (Client-Broker-Client) en 250-300 microsegundos. Vea aquí para una comparación con la latencia de Windows (que fue un poco más alta) http://old.nabble.com/high%28er%29-latency-with-1.5.1-p21663105.html

No puedo pensar en muchos juegos multijugador que necesiten latencia de ida y vuelta inferior a 300 microsegundos. Podrías obtener por debajo de 300US con TCP. Ventana TCP es Más caro que UDP en bruto, pero si usa UDP para ir más rápido y agrega un recuperación de pérdida personalizada o SEQNO/ACK/Resend Manager, eso puede retrasarlo nuevamente. Todo depende de su caso de uso. Si realmente realmente necesita usar UDP y ACKS perezoso, etc., entonces podría eliminar el TCP de RabbitMQ y probablemente lograrlo.

Espero que esto ayude a aclarar por qué recomendé RabbitMQ para el caso de uso de Jon.

Answer 2

Estoy construyendo ese sistema ahora, en realidad.

He realizado una buena cantidad de evaluación de varios MQ, incluidos RabbitMQ, QPID y Zeromq. La latencia y el rendimiento de cualquiera de ellos son más que adecuados para este tipo de aplicación. Sin embargo, lo que no es bueno es el tiempo de creación de colas en medio de medio millón de colas o más. QPID en particular se degrada bastante severamente después de unos pocos miles de colas. Para eludir ese problema, generalmente tendrá que crear sus propios mecanismos de enrutamiento (un número menor de colas totales, y los consumidores en esas colas están recibiendo mensajes en los que no tienen interés).

Mi sistema actual probablemente usará Zeromq, pero de una manera bastante limitada, en el interior el clúster. Las conexiones de los clientes se manejan con un SIM personalizado. demonio que construí usando libev y es completamente de un solo subproceso (y muestra una escala muy buena: debería poder manejar 50,000 conexiones en una caja sin ningún problema: nuestra tasa de tics sim. es bastante baja, y hay sin física).

XML (y, por lo tanto, XMPP) no es muy adecuado para esto, ya que obtendrá el procesamiento de CPU XML mucho antes de que se atance en E/S, que no es lo que desea. Estamos utilizando Google Protocol Buffers, en este momento, y los parecen muy adecuados para nuestras necesidades particulares. También estamos usando TCP para las conexiones del cliente. He tenido experiencia en el uso de UDP y TCP para esto en el pasado, y como lo señalaron otros, UDP tiene alguna ventaja, pero es un poco más difícil trabajar con él.

Con suerte, cuando estemos un poco más cerca del lanzamiento, podré compartir más detalles.

Answer 3

Jon, esto suena como un caso de uso ideal para AMQP y RabbitMQ.

No estoy seguro de por qué dice que los usuarios de AMQP son grandes corporaciones de tipo empresarial. Más de la mitad de nuestros clientes están en el espacio 'web' que van desde grandes hasta pequeñas empresas. Muchos juegos, sistemas de apuestas, sistemas de chat, sistemas de tipo Twittery e infras de computación en la nube se han construido con RabbitMQ. Incluso hay aplicaciones de teléfonos móviles. Los flujos de trabajo son solo uno de los muchos casos de uso.

Intentamos realizar un seguimiento de lo que está pasando aquí:

http://www.rabbitmq.com/how.html (Asegúrese de hacer clic en las listas de casos de uso en del.icio.us también!)

Por favor, eche un vistazo. Estamos aquí para ayudar. No dude en enviarnos un correo electrónico a info@rabbitmq.com o golpearme en Twitter (@Monadic).

Answer 4

FWIW, para los casos en que los resultados intermedios no son importantes (como la información de posicionamiento), QPID tiene una "cola de último valor" que solo puede entregar el valor más reciente a un suscriptor.

Answer 5

Mi experiencia fue con una alternativa no abierta, BizTalk. La lección más dolorosa que aprendimos es que estos sistemas complejos no son rápidos. Y como pensó en los requisitos de hardware, eso se traduce directamente en costos significativos.

Por esa razón, ni siquiera se acerque a XML para las interfaces centrales. Su clúster de servidor analizará 2 millones de mensajes por segundo. ¡Eso podría ser fácilmente 2-20 GB/seg de XML! Sin embargo, la mayoría de los mensajes serán para algunas colas, mientras que la mayoría de las colas son de hecho de bajo tráfico.

Por lo tanto, diseñe su arquitectura para que sea fácil comenzar con los servidores de cola COTS y luego mover cada cola (tipo) a un servidor de cola personalizado cuando se identifica un cuello de botella.

Además, por razones similares, no asuma que una arquitectura de cola de mensajes es la mejor para todas las necesidades de cominicación que tiene su aplicación. Tome su ejemplo de "ubicación de entidad en una instancia". Este es un caso clásico en el que no Desea la entrega de mensajes garantizados. La razón por la que necesita compartir esta información es porque cambia todo el tiempo. Entonces, si se pierde un mensaje, no desea pasar tiempo recuperándolo. Solo enviarías el antiguo locationiom de la entidad afectada. En cambio, querrías enviar el Actual Ubicación de esa entidad. En cuanto a la tecnología, esto significa que desea UDP, no TCP y un mecanismo de recuperación de pérdida personalizado.