Cola de mensajes de baja latencia y gran escala

Estoy construyendo tal sistema ahora, en realidad.

He hecho una buena cantidad de evaluación de varios MQs, incluyendo RabbitMQ, Qpid y ZeroMQ. La latencia y el rendimiento de cualquiera de ellos son más que adecuados para este tipo de aplicaciones. Lo que no es bueno, sin embargo, es el tiempo de creación de colas en medio de medio millón de colas o más. Qpid en particular se degrada severamente después de unos pocos miles de colas. Para evitar ese problema, normalmente tendrá que crear su propio mecanismos de enrutamiento (menor número de colas totales, y los consumidores en esas colas reciben mensajes en los que no tienen interés).

Mi sistema actual probablemente usará ZeroMQ, pero de una manera bastante limitada, dentro de el clúster. Las conexiones de los clientes se manejan con una sim personalizada. daemon que construí usando libev y es completamente de un solo hilo (y está mostrando muy buena escala should debería ser capaz de manejar 50,000 conexiones en una caja sin ningún problema our nuestro SIM. sin embargo, la tasa de garrapatas es bastante baja, y no hay física).

XML (y por lo tanto XMPP) no es muy adecuado para esto, ya que pegará el XML de procesamiento de la CPU mucho antes de quedar enlazado en E/S, que no es lo que desea. Estamos usando Búferes de protocolo de Google, en este momento, y esos parecen muy adecuados para nuestras necesidades particulares. También estamos usando TCP para las conexiones del cliente. He tenido experiencia usando UDP y TCP para esto en el pasado, y como han señalado otros, UDP lo hace tener alguna ventaja, pero es un poco más difícil de trabajar con.

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

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

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

Tratamos de mantener pista 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 [email protected] o me golpeó en twitter (@monadic).

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

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 se imaginó a partir de los requisitos de hardware, eso se traduce directamente en costos significativos.

Por esa razón, ni siquiera se acerque a XML para las interfaces principales. Su clúster de servidores 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 están en hecho de poco 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 identifique 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 comunicación que tiene su aplicación. Tome el ejemplo de "ubicación de la entidad en una instancia". Este es un caso clásico en el que no quiere una entrega de mensajes garantizada. El la razón por la que necesita compartir esta información es porque cambia todo el tiempo. Por lo tanto, si se pierde un mensaje, no querrá pasar tiempo recuperándolo. Sólo enviarías la antigua ubicación de la entidad afectada. En su lugar, usted querrá enviar la ubicación actual de esa entidad. En cuanto a la tecnología, esto significa que desea UDP, no TCP y un mecanismo personalizado de recuperación de pérdidas.