Le middleware de messages est une technologie de middleware composée d’un mécanisme de transmission de messages ou d’un mode file d’attente de messages, qui utilise un mécanisme de messagerie efficace et fiable pour l’échange de données indépendant de la plateforme, et intègre des systèmes distribués basés sur la communication de données. Actuellement, il existe de nombreux produits MQ dans l’industrie, tels que RabbitMQ, ActiveMQ, ZeroMQ, etc., qui sont d’excellents middlewares de messages, mais lequel devrions-nous choisir dans le projet ? Cet article évalue et compare les produits de file d’attente de messages suivants : RabbitMQ, ZeroMQ, ActiveMQ, MSMQ, Redis et memcacheQ
Digression : Ici, nous pouvons d’abord réfléchir à une petite question : « Pourquoi avons-nous besoin de services de file d’attente de messages dans les applications web ? » ”
Par exemple, un grand nombre de requêtes d’insertion, de mise à jour et d’autres arrivent simultanément sur MySQL, ce qui entraîne directement d’innombrables verrous de lignes et de tables, voire trop de requêtes au final, déclenchant ainsi trop d’erreurs de connexion. En utilisant des files d’attente de messages, nous pouvons traiter les requêtes de manière asynchrone, allégeant ainsi la pression sur le système.
RabbitMQ
Il s’agit d’une file d’attente de messages open source écrite en Erlang, qui prend en charge de nombreux protocoles : AMQP, XMPP, SMTP, STOMP, ce qui la rend très lourde et plus adaptée au développement au niveau entreprise. C’est une implémentation majeure du protocole AMQP, qui implémente une architecture de courtier, ce qui signifie que les messages peuvent être mis en file d’attente sur un nœud central avant d’être envoyés au client. Il existe un bon support pour le routage, l’équilibrage de charge ou la persistance des données. Cette fonctionnalité rend RabbitMQ facile à utiliser et à déployer, adapté à de nombreux scénarios tels que le routage, l’équilibrage de charge ou la persistance des messages, et peut être réalisée avec seulement quelques lignes de code via des files d’attente de messages. Cependant, cela le rend moins évolutif et plus lent car le nœud central augmente la latence et devient plus important après l’encapsulation du message. Pour configurer RabbitMQ, vous devez installer l’environnement Erlang sur la machine cible.
Cliquez pour voir cette image dans une nouvelle fenêtre
? MQ(ZeroMQ)
Il est connu comme le système de file d’attente de messages le plus rapide, notamment pour les scénarios de demande à haut débit. C’est un système de messagerie très léger développé spécifiquement pour des scénarios à haut débit/faible latence, et que l’on trouve souvent dans des applications du monde financier. Comparé à RabbitMQ, ZeroMQ prend en charge de nombreux scénarios de messages avancés, mais il faut implémenter des blocs individuels dans le cadre ZeroMQ (comme des sockets ou des périphériques, etc.).
? MQ (ZeroMQ) peut implémenter des files d’attente avancées/complexes que RabbitMQ ne maîtrise pas bien, mais les développeurs doivent combiner eux-mêmes plusieurs frameworks techniques, et la complexité technique constitue un défi pour l’application réussie de ce MQ. ZeroMQ propose un modèle unique non middleware où vous n’avez pas besoin d’installer et d’exécuter un serveur de messages ou un middleware, car votre application jouera ce rôle de service. Il suffit de référencer la bibliothèque ZeroMQ, qui peut être installée via NuGet, et vous pouvez facilement envoyer des messages entre applications. Cependant, ZeroMQ ne fournit que des files d’attente non persistantes, ce qui signifie que si la machine tombe en panne, les données seront perdues. Parmi eux, Storm de Twitter utilise ZeroMQ pour la transmission des flux de données. ZeroMQ est très flexible, mais il faut apprendre son manuel de 80 pages (si vous écrivez sur un système distribué, assurez-vous de le lire).
ZeroMQ ne possède pas d’architecture middleware et ne nécessite aucun processus de service ni exécution. En fait, votre endpoint d’application joue ce rôle de service. Cela rend le déploiement très simple, mais le problème est que vous n’avez nulle part où surveiller si quelque chose tourne mal. À notre connaissance, ZeroMQ ne propose que des files d’attente non persistantes. Vous pouvez mettre en place vos propres capacités d’audit et de récupération de données là où vous en avez besoin.
Cliquez pour voir cette image dans une nouvelle fenêtre
MSMQ
C’est la seule chose du produit Microsoft qui est considérée comme précieuse. Si MSMQ peut prouver qu’il peut gérer ce type de tâche, ils choisiront de l’utiliser. Le fait est que cette chose n’est pas compliquée, rien que recevoir et envoyer ; Il comporte certaines limitations strictes, comme la taille maximale du message de 4 Mo. Cependant, il peut résoudre ces problèmes en se connectant à des logiciels comme MassTransit ou NServiceBus.
Cliquez pour voir cette image dans une nouvelle fenêtre
Jafka/Kafka
Kafka (qui distribue les messages entre différents nœuds) est un système MQ distribué développé et open source par LinkedIn en décembre 2010, et il est désormais un projet d’incubation d’Apache, un système de file d’attente distribué multi-langues haute performance pour publier/s’abonner à messages, et Jafka est incubé au-dessus de Kafka, qui est une version améliorée de Kafka. Il possède les caractéristiques suivantes : persistance rapide, qui peut faire persister les messages sous la surcharge système de O(1) ; Haut débit, pouvant atteindre un débit de 10W/s sur un serveur ordinaire ; Système entièrement distribué, courtier, producteur et consommateur supportent tous nativement le système distribué et atteignent automatiquement l’équilibre complexe. Prend en charge le chargement parallèle des données Hadoop, ce qui est une solution viable pour les données de journal et les systèmes d’analyse hors ligne comme Hadoop, mais avec les limites du traitement en temps réel. Kafka unifie le traitement des messages en ligne et hors ligne via le mécanisme de chargement parallèle de Hadoop, ce qui est également important pour le système étudié dans ce domaine. Apache Kafka est un système de messagerie très léger par rapport à ActiveMQ, et en plus de ses très bonnes performances, c’est aussi un système distribué qui fonctionne bien.
Cliquez pour voir cette image dans une nouvelle fenêtre
Apache ActiveMQ
ActiveMQ se situe quelque part entre les deux (RabbitMQ et ZeroMQ), similaire à ZemoMQ, et peut être déployé en modes proxy et P2P. À l’instar de RabbitMQ, il est facile d’implémenter des scénarios avancés et nécessite une faible consommation.
ActiveMQ est reconnu comme la colonne vertébrale du monde Java. Il a une longue histoire et est largement utilisé. Il est aussi multiplateforme, offrant un point d’accès naturel pour les produits qui ne sont pas sur la plateforme Microsoft. Cependant, il n’est possible d’être considéré que s’il a dépassé MSMQ. Pour configurer ActiveMQ, vous devez installer l’environnement Java sur la machine cible.
Cliquez pour voir cette image dans une nouvelle fenêtre
Il est important de noter que le produit de nouvelle génération d’ActiveMQ est Apollo, basé sur le prototype ActiveMQ et un outil de courtier de messages plus rapide, plus fiable et plus facile à entretenir. Apache qualifie Apollo de serveur STOMP (Streaming Text Oriented Message Protocol) le plus rapide et le plus robuste.
Les caractéristiques d’Apollo sont les suivantes :
Les protocoles Stomp 1.0 et Stomp 1.1 sont pris en charge
Sujets et files d’attente
Navigateur de files d’attente
Abonnements persistants à thème
File d’attente miroir
Messagerie fiable
Expiration et échange des messages
Sélecteur de messages
Vérifié par JAAS
Autorisation basée sur ACL
Prise en charge SSL/TLS et validation de certificats
API de gestion REST
Cliquez pour voir cette image dans une nouvelle fenêtre
Redis
Il s’agit d’une base de données NoSQL clé-valeur, qui est activement développée et maintenue, bien qu’il s’agisse d’un système de stockage de base de données clé-valeur, mais elle prend en charge les fonctions MQ, ce qui la permet d’être utilisée comme service de file d’attente léger. Pour les opérations d’intégration et de sortie d’attente de RabbitMQ et Redis, 1 million de fois chacune, et le temps d’exécution est enregistré toutes les 100 000 fois. Les données de test sont divisées en quatre tailles différentes : 128 octets, 512octets, 1K et 10K. Les expériences montrent qu’en rejoignant l’équipe, les performances de Redis sont supérieures à celles de RabbitMQ lorsque la comparaison des données est petite, et si la taille des données dépasse 10 000, Redis est insupportablement lent. En sortant de l’équipe, Redis a montré de très bonnes performances quelle que soit la taille des données, tandis que la performance de RabbitMQ était bien inférieure à celle de Redis.
MemcacheQ
File d’attente de messages persistants Memcacheq (MCQ en abrégé) est une file d’attente de messages légère, avec des fonctionnalités MemcacheQ :
1 Simple et facile à utiliser
2 Traitement rapide
3 Files d’attente multiples
4 Bonne performance de concurrence
5 Compatible avec le protocole Memcache. Cela signifie qu’il suffit d’installer l’extension memcache, aucun plugin supplémentaire n’est nécessaire.
6 Il est également pratique à utiliser dans le cadre Zend.
En fin de compte, ces produits :
1. Les deux disposent de leurs propres API clients ou prennent en charge plusieurs langages de programmation ;
2. Il y a beaucoup de documentation ;
3. Un soutien positif a été apporté.
4. ActiveMQ, RabbitMQ, MSMQ, Redis doivent tous démarrer des processus de service, qui peuvent être surveillés et configurés, et les autres posent problème
5. Ils offrent tous une fiabilité relativement bonne (cohérence), une scalabilité et un équilibrage de charge, et bien sûr, des performances
Je ne vais pas dire de bêtises ici, ci-dessous vous trouverez ci-dessous un ensemble de résultats de tests interceptés sur Internet. Le nombre de messages envoyés et reçus par seconde est affiché. L’ensemble du processus a généré un total de 1 million de messages de 1 000 messages. Le test a été réalisé sur une machine autonome Windows Vista.
Comme vous pouvez le voir, ZeroMQ n’est pas un niveau comme les autres. Ses performances sont étonnamment élevées. Malgré cela, ce produit ne fournit pas de persistance des messages, ne peut pas facilement stocker et surveiller les processus intermédiaires, et nécessite une auto-vérification et une récupération de données, ce qui le rend insatisfaisant en termes de facilité d’utilisation et d’authentification des données. La conclusion est claire : si vous voulez qu’une application envoie des messages aussi rapidement que possible, vous choisissez ZeroMQ. C’est plus précieux quand on ne se soucie pas trop de perdre certains messages par hasard.
Le blogueur de cet article espère (et n’espère pas beaucoup) utiliser Rabbit, Rabbitmq a un système intégré ha, si vous formez un cluster, il n’y a pas besoin de s’inquiéter de problèmes comme l’équilibrage de charge, et vous pouvez configurer un miroir de file d’attente. Mais ce genre de chose, c’est qu’il devrait y avoir plus de tests, et on finit par avoir un favori, et tout ce que j’ai entendu et lu sur Rabbit me fait penser que c’est le meilleur choix.
|
Publié sur 15/12/2016 10:52:40
|
|
|
|
