Solución de puesta en cola de mensajes para millones de temas

Question

Estoy pensando en el sistema que notificará a múltiples consumidores sobre eventos que suceden a una población de objetos. Cada suscriptor debe poder suscribirse a los eventos que suceden a cero o más de los objetos, múltiples suscriptores deben poder recibir información sobre los eventos que suceden a un solo objeto.

Creo que algún sistema de colas de mensajes será apropiado en este caso, pero no estoy seguro de cómo manejar el hecho de que tendré millones de objetos, usar un tema separado para cada uno de los objetos no suena bien [¿o está bien?].

¿Puede sugerir el enfoque que debería tomar y tal vez incluso algún sistema de cola de mensajes de código abierto que sería razonable?

algunos detalles más:

• habrá miles de abonados [es decir, no un montón de ellos],
• suscriptores suscribirse a decenas o cientos de objetos cada uno,
• habrá ~ 5 -20 millones de los objetos,
• mismos eventos no tienen que llevar ningún mensaje. la información sólo que ese objeto se ha cambiado es suficiente,
• gran mayoría de los objetos nunca será suscrito,
• eventos ocurren a la velocidad máxima de unos cientos por segundo,
• ideal es que el servidor debe ejecutar en Linux, ya sea capaz de integrarse con el resto del ecosistema a través de http long-poll [utilizando el nodo js? continuaciones bajo embarcadero?].

Gracias de antemano por sus comentarios y lo siento por algo tan vaga pregunta!

Answer 1

Desglose los temas para llevar eventos específicos para, p. Ej. "Tema actualizado del objeto" "Objeto eliminado" ... Para que los clientes solo tengan que suscribirse al "finito no" de los temas basados ​​en eventos en los que están interesados.

Inyecte los encabezados en sus mensajes cuando los publica y poner inteligencia en los clientes para usar estos encabezados como selectores de mensajes. Por ejemplo, el cliente conoce la lista de objetos que le interesan y dice que identifica el objeto con un "id", la identificación puede ser el encabezado y el cliente usará el "encabezado de identificación" para determinar si está interesado en el mensaje.

Dependiendo de si lo desea, también puede considerar garantizar la entrega garantizada para asegurarse de que el cliente recibirá el mensaje incluso si se desconecta y regresa más tarde.

Las opciones que recomendaría la parte superior de la cabeza están ActiveMQ, RabbitMQ y SUB Redis PUB (no he realmente trabajaron en Redis pub-sub, por favor utilice su debido diligance)

Finalmente aquí están algunos puntos de referencia de rendimiento para RabbitMQ y Redis

Acabo de ver que solo tienen unos 100 mensajes expulsados ​​/ seg. Esto no es un gran problema para activemq, he estado usando Amq en un sistema que procesa 240 mensajes por segundo y funciona bien. . Sin embargo, utilizo un grupo de subprocesos de trabajadores para procesar asincrónicamente los mensajes. Mire un marco como akka si está en la tierra de Java, si no se adhiere a nodejs y al Cool sistema ecológico que lo rodea.

Answer 2

Si tiene que ser de código abierto que volvería a ActiveMQ, y un servidor de aplicaciones para proporcionar la funcionalidad de JMS para temas y tiene Ajax Support para que pueda acceder a ellos desde su cliente

Por lo tanto, se utilizaría la infraestructura JMS para publicar los temas para los objetos, y usted can create topis as you need them

Además, mediante el uso de un servidor de aplicaciones java, puede aprovechar las ventajas del clúster, equilibrio de carga y otras características de alta disponibilidad (obviamente basadas en el producto seleccionado)

¡Espero que ayude!

Answer 3

Lo recomiendo encarecidamente RabbitMQ. Lo he usado en un par de proyectos antes y, según mi experiencia, creo que es muy confiable y ofrece una amplia gama de configuraciones. Básicamente, RabbitMQ es un intermediario de mensajes open-source (Licencia pública de Mozilla (MPL)) que implementa el estándar Advanced Message Queuing Protocol (AMQP).

tal como se documenta en el sitio web RabbitMQ:

RabbitMQ potencialmente puede funcionar en cualquier plataforma que soporta Erlang, desde sistemas embebidos a la multi-núcleo clústeres y servidores basados ​​en la nube.

... lo que significa que se admite un sistema operativo como Linux.

Hay una biblioteca de Node.js aquí: https://github.com/squaremo/rabbit.js

Viene con una API basada en HTTP para la gestión y supervisión del servidor RabbitMQ - incluyendo una herramienta de línea de comandos y una interfaz de usuario basada en navegador como bien - vea: http://www.rabbitmq.com/management.html.

En los proyectos con los que he estado trabajando, me he comunicado con RabbitMQ usando C# y dos envoltorios diferentes, EasyNetQ y Burrow.NET. Ambas son excelentes envolturas para RabbitMQ, pero terminé siendo la más entusiasta de Burrow.NET, ya que es más fácil y más obvio trabajar con él (no hace mucha magia debajo del capó) y proporciona una buena flexibilidad para inyectar registradores, serializadores, etc.

Nunca he trabajado con la cantidad de objetos con los que va a trabajar: he trabajado con miles (no millones). Sin embargo, no importa cuántos objetos haya estado jugando, RabbitMQ siempre ha funcionado realmente estable y nunca ha sido la fuente de errores en el sistema.

Resumiendo, RabbitMQ es fácil de usar y de configurar, admite AMQP, se puede administrar a través de HTTP y lo que más me gusta, es sólido como una roca.

Answer 4

Aunque no estoy seguro de su entorno de trabajo, pero aquí están mis bits. ¿Puedes identificar cada objeto con una identificación única en tu sistema? Si es así, puede tener un tema por cada tipo de evento. por ej. desea rastrear el evento de eliminación de objetos, el evento de actualización de objetos, etc. Entonces puedes tener un tema para cada tipo de evento. Estos temas se publicarían con Id. De objeto siempre que el evento correspondiente ocurra con el objeto. Esto limitará el número de temas que necesita. La segunda parte de su problema es que los suscriptores diferentes quieren suscribirse a diferentes objetos. Entonces, no todos los suscriptores están interesados ​​en conocer eventos de todos los objetos. Este enunciado de problema tiene como ámbito el mecanismo selector de mensajes (filtrado) proporcionado por el marco de mensajería. Entonces, básicamente, debe buscar sobre qué base un suscriptor interesado en un objeto particular. Tener esa base como un mecanismo de filtrado de mensajes.Podría ser cualquier cosa: tipo de objeto, estado de objeto, etc. Por lo tanto, en última instancia, su sistema consistiría en un tema para cada tipo de evento con alguien que publique mensajes de evento: {object-type: object-id} información. Los suscriptores pueden suscribirse a cualquier tema y con un criterio de filtrado.

Si la solución anterior satisface, puede usar cualquier solución de mensajería: activeMQ, WMQ, RabbitMQ.

Answer 5

Dado que sus mensajes son muy pequeños, podría considerar MQTT, que está diseñado para dispositivos pequeños, aunque también funciona bien en dispositivos potentes. La consideración clave es la baja sobrecarga, básicamente un encabezado de 2 bytes para un mensaje pequeño. Probablemente no pueda usar ningún servidor MQTT de fuente abierta o simple, debido a su volumen. Probablemente necesite un dispositivo dedicado de servicio pesado como MessageSight para manejar su volumen.

Algunos más detalles sobre su aplicación sin duda ayudaría. Además, no mencionas seguridad en absoluto. Supongo que debe tener algunas necesidades en esta área.