Performance de messagerie transitoire haute vitesse RabbitMQ

Question

Le système que nous sommes en train de générer reçoit des données via le flux externe. Notre travail consiste à distribuer ces données à plusieurs services, à exécuter les calculs et à transmettre les résultats ailleurs - situation typique d'un éditeur et d'un abonné. Ce dont nous avons besoin, c'est d'une messagerie à très faible latence. Nous n'avons pas besoin de persister les messages comme MSMQ.

RabbitMq est-il assez rapide pour une livraison de message en temps réel? Y a-t-il des repères? Est-ce une bonne idée de l'utiliser à la place de TIBCO Rendezvous? Existe-t-il d'autres solutions de messagerie logicielle en temps réel, à code source libre?

Merci.

Answer 1

(Je suis un développeur de rabbitmq.)

lapin, une charge légère ont généralement latences de l'ordre de 100-400 microsecondes, en fonction de choses comme votre carte réseau et la vitesse du processeur. Une fois que le chargement devient un peu plus lourd, le tampon interne commence à apparaître et les latences augmentent un peu. Vous pouvez sans risque attendre des latences 1ms jusqu'à ce que l'utilisation de la bande passante (messages par seconde, octets par seconde) commence à être élevée. Les latences augmenteront aussi une fois la persistance introduite, naturellement. En ce qui concerne les benchmarks, l'un des plus gros problèmes ici est de définir ce qui est important pour votre application. Il y a quelques exemples de mesure de la latence et du débit de point à point et de sous-pub trivialement simples inclus avec le client Java; demander sur la liste de Rabbitmq-discuter si vous avez des problèmes avec eux! Ils ne mesurent pas beaucoup de pertinence pour les applications du monde réel, mais pourraient aider à apaiser les préoccupations que vous avez concernant les microbenchmarks de latence ou de débit. Enfin, il existe de nombreux systèmes de messagerie et de messagerie open-source de bonne qualité disponibles ces jours-ci. Dans le monde d'AMQP seul, en plus de RabbitMQ, il y a aussi Qpid et OpenAMQ. Il existe également de bons serveurs JMS open-source, si vous êtes capable de vous limiter à Java (beaucoup de gens ont du succès avec ActiveMQ). Beaucoup de systèmes légers se développent également pour les systèmes Ruby et Python; ces systèmes ont tendance à se concentrer uniquement sur la mise en file d'attente et n'ont généralement pas la capacité de routage flexible qu'offre l'AMQP.

Answer 2

Vous devriez être capable d'atteindre plusieurs dizaines de milliers de messages par seconde par CPU. Par exemple, un de nos tests standard envoie 25k messages par seconde depuis un client Java vers le serveur fonctionnant sur une boîte debian COTS quad core, et renvoyé au client. Le client et le serveur s'exécutent sur la même case, ce qui signifie que 50k messages sont traités par seconde sur le serveur plus 50k messages traités par seconde sur le client. Vous pouvez obtenir des taux plus élevés en exécutant le serveur sur une boîte dédiée avec plus de cœurs. Pour les tarifs basés sur les octets/seconde, veuillez vous renseigner sur la liste de diffusion rabbitmq-discuss.

alexis

Answer 3

La meilleure solution que je peux penser à votre système est ZeroMQ.

Il n'a pas la persistance, que vous avez dit que vous n'avez pas besoin et c'est très rapide et simple à utiliser.

Ce n'est pas une implémentation AMQP (qu'il vous semble que vous ne avez pas besoin), mais comme il est dit sur this guide:

omq (ZeroMQ, 0MQ, ZMQ) ressemble à une bibliothèque de réseau intégrable, mais agit comme un cadre de concurrence. Il vous donne des sockets qui transportent des messages entiers à travers différents transports comme en cours, inter-processus, TCP et multicast. Vous pouvez connecter des sockets N-to-N avec des motifs tels que fanout, pub-sub, répartition des tâches et request-reply.C'est assez rapide pour être le tissu des produits en cluster. Son modèle d'E/S asynchrone vous donne des applications multicœurs évolutives, construites comme des tâches de traitement de messages asynchrones. Il a une vingtaine d'API de langage et fonctionne sur la plupart des systèmes d'exploitation.