À quoi sert l'impressionnant RabbitMQ?

Pile technologique Java

www.javastack.cn

Suivez pour lire plus d'articles de qualité

Auteur: Sea to
Source: www.cnblogs.com/haixiang/p/10199754.html

1. Introduction à RabbitMQ

MQ est appelé Message Queue et Message Queue ( MQ ) est une méthode de communication d'application à application. Les applications communiquent en lisant et en écrivant des messages (pour les données d'application) entrant et sortant de la file d'attente, sans avoir besoin d'une connexion dédiée pour les lier.

Le passage de messages fait référence à la communication entre programmes en envoyant des données dans des messages, plutôt qu'en s'appelant directement les uns les autres pour communiquer. L'appel direct est généralement utilisé pour des technologies telles que les appels de procédure à distance. La mise en file d'attente fait référence aux applications qui communiquent via des files d'attente. L'utilisation de files d'attente élimine la nécessité d'une exécution simultanée des applications de réception et d'envoi.

RabbitMQ est un système de file d'attente de messages open source développé en utilisant le langage Erlang et implémenté sur la base du protocole AMQP. Les principales caractéristiques d'AMQP sont orientées messages, file d'attente, routage (y compris point à point et publication / abonnement), fiabilité et sécurité.

Le protocole AMQP est plus utilisé dans les systèmes d'entreprise. Pour les scénarios nécessitant une cohérence, une stabilité et une fiabilité des données élevées, les exigences en matière de performances et de débit sont en second lieu.

2. Scénarios d'utilisation de RabbitMQ

1. Découplage (fournissant une implémentation de base de cohérence éventuelle pour l'architecture orientée services (SOA))

Description du scénario: une fois que l'utilisateur a passé une commande, le système de commande doit en informer le système d'inventaire. L'approche traditionnelle est que le système de commande appelle l'interface du système d'inventaire.

Inconvénients du modèle traditionnel:

  • Si le système d'inventaire est inaccessible, la réduction de commande échouera, entraînant l'échec de la commande

  • Couplage du système de commande et du système d'inventaire

Présentation de la file d'attente des messages

  • Système de commande: une fois que l'utilisateur a passé une commande, le système de commande termine le traitement de la persistance, écrit le message dans la file d'attente des messages et renvoie la commande de l'utilisateur pour être passée avec succès

  • Système d'inventaire: abonnez-vous aux informations de commande, utilisez la méthode pull / push pour obtenir des informations sur la commande et le système d'inventaire effectue des opérations d'inventaire en fonction des informations de commande

  • Si: Le système d'inventaire ne peut pas être utilisé normalement lorsque la commande est passée. Cela n'affecte pas le placement normal de la commande, car une fois la commande passée, le système de commande écrit dans la file d'attente des messages et ne se soucie plus des autres opérations de suivi. Réaliser le découplage applicatif du système de commande et du système d'inventaire

  • Afin de vous assurer que l'inventaire est bien là, vous pouvez définir la taille de la file d'attente sur la quantité d'inventaire ou utiliser d'autres méthodes pour le résoudre.

Le modèle basé sur les messages se soucie de la «notification» plutôt que du «traitement».

Les SMS, les notifications par e-mail, l'actualisation du cache et d'autres opérations utilisent la file d'attente de messages pour la notification.

La différence et la comparaison entre la file d'attente de messages et RPC:

RPC : appel asynchrone, obtenez les résultats des appels à temps, obtenez des résultats de cohérence solides, se soucient des résultats du traitement des appels professionnels.

File d'attente de messages: deux appels RPC asynchrones , vider le contenu de l'appel dans la file d'attente et sélectionner l'heure appropriée pour la livraison (contrôle de flux de pointe de décalage)

2. Améliorez l'efficacité de manière asynchrone

Description du scénario: après l'inscription, les utilisateurs doivent envoyer un e-mail d'inscription et un SMS d'inscription. Il existe deux méthodes traditionnelles 

1. mode série; 2. mode parallèle

(1) Mode série: après avoir écrit avec succès les informations d'enregistrement dans la base de données, envoyez l'e-mail d'enregistrement, puis envoyez le SMS d'enregistrement. Une fois les trois tâches ci-dessus terminées, retournez voir le client

(2) Mode parallèle: une fois les informations d'enregistrement écrites avec succès dans la base de données, le message d'enregistrement est envoyé en même temps que l'e-mail d'enregistrement. Une fois les trois tâches ci-dessus terminées, retournez voir le client. La différence avec la série est que la méthode parallèle peut augmenter le temps de traitement

(3) L'introduction de files d'attente de messages ne sera pas une logique métier nécessaire, un traitement asynchrone. La structure reconstruite est la suivante:

3. Coupure des pics de trafic

La réduction du trafic est également un scénario courant dans les files d'attente de messages, qui est généralement largement utilisé dans les activités de pointe ou de capture de groupe. À propos des articles de la série Spike, vous pouvez suivre la pile de la technologie Java du compte officiel pour la lecture.

Scénario d'application: à d'autres moments du système, le système A a 100 requêtes par seconde et le système peut fonctionner de manière stable. Le système a une activité de pointe à 8 heures chaque nuit, et le nombre de requêtes simultanées par seconde est passé à 10000, mais la capacité de traitement maximale du système ne peut traiter que 1000 requêtes par seconde, de sorte que le système se bloque et le serveur tombe en panne.

Architecture précédente: Un grand nombre d'utilisateurs (1 million d'utilisateurs) participent à l'activité de pointe en même temps au pic de 8 heures du soir via le navigateur. Un grand nombre de requêtes ont inondé notre système, la période de pointe a atteint 5000 requêtes par seconde, un grand nombre de requêtes a atteint MySQL et il est prévu d'exécuter 3000 SQL par seconde.

Cependant, le MySQL général est bon pour traiter 2000 requêtes par seconde. S'il atteint 3000 requêtes, MySQL peut être directement paralysé et le système ne peut pas être utilisé. Cependant, après la période de pointe, cela devient une période de pointe faible: il se peut que seulement 10 000 utilisateurs accèdent au système et le nombre de requêtes par seconde n'est que d'environ 50. Il n'y a presque pas de pression sur l'ensemble du système.

Introduire MQ : pendant la période de pointe de 1 million d'utilisateurs, il y a environ 5 000 requêtes par seconde. Écrivez ces 5 000 requêtes dans MQ. Le système A ne peut traiter que 2 000 requêtes par seconde, car MySQL ne peut traiter que 2 000 requêtes par seconde. demande.

Le système A extrait lentement les demandes de MQ et tire 2000 demandes par seconde, sans dépasser le nombre de demandes qu'il peut traiter par seconde. MQ , 5000 demandes arrivent chaque seconde, mais seulement 2000 demandes sont envoyées, donc pendant la période de pointe (près d'une heure), des centaines de milliers ou des millions de demandes peuvent être en retard dans MQ.

Ce backlog de courte période de pointe ne pose aucun problème, car après la période de pointe, seules 50 requêtes par seconde entrent dans le MQ, mais le système est toujours en train de traiter au taux de 2000 requêtes par seconde, tant que la période de pointe est de un. Après cela, le système consommera rapidement l'arriéré de messages.

Calculons ici qu'il y a 3000 messages dans le backlog MQ par seconde, 180000 messages en 1 minute, 10 millions de messages en 1 heure, après la période de pointe, le backlog de 10 millions de messages peut être consommé en plus d'une heure.

3. Les avantages et les inconvénients de l'introduction de files d'attente de messages

avantage

L'avantage est que les scénarios ci-dessus ont leurs avantages correspondants dans des scénarios spéciaux, tels que le découplage, l'asynchronie et l'écrêtage des pics.

Désavantage

  • La disponibilité du
    système diminue. Plus le système introduit de dépendances externes, plus il est facile pour le système de raccrocher. À l'origine, c'était juste que le système A appelait les trois interfaces système de BCD, et les quatre systèmes d'ABCD fonctionnaient normalement sans erreur. Après l'introduction de MQ , bien que le système ABCD n'ait pas commis d'erreur , l'ensemble du système se plantera également après le blocage de MQ .

  • La complexité du système a augmenté. Après l'
    introduction de MQ, d'autres problèmes doivent être pris en compte. Comment s'assurer que les messages ne sont pas consommés à plusieurs reprises? Comment s'assurer que le message n'est pas perdu? Comment garantir l'ordre de livraison des messages?

  • Problème de cohérence
    Un système renvoie un succès après l'envoi du message, mais en cas de défaillance de la bibliothèque d'écriture système dans le système BCD, une incohérence des données se produit.

Pour résumer

Donc en résumé, la file d'attente de messages est une architecture très complexe, il y a de nombreux avantages à l'introduire, mais diverses solutions techniques et architectures supplémentaires doivent être apportées pour éviter les inconvénients qu'elle apporte.

La complexité de l' introduction du système MQ a augmenté d'un ordre de grandeur, mais dans certains scénarios, elle est dix fois cent fois plus compliquée, et MQ est toujours nécessaire .

Articles chauds récents:

1. J'ai écrit un morceau de logique en Java 8, mais mes collègues ne pouvaient pas le comprendre directement

2. Notes d'étude de Spring Boot, c'est trop complet!

3. Accrochez Tomcat, les performances Undertow sont très explosives! !

4. Spring Boot est trop cruel, sortez 3 versions à la fois!

5. Comment Spring Boot intègre-t-il Redis rapidement?

6 、La dernière version du "Manuel de développement Java (édition Songshan)"

7. Spring Boot Redis implémente des verrous distribués, ce qui est si parfumé!

8. Chinese open source une petite et complète bibliothèque d'outils Java !

9. Le chinois open source a un client Redis super facile à utiliser! !

dix,Mon collègue a écrit un bug caché, et je l'ai vérifié pendant 3 jours!

Scannez le code QR pour suivre le compte officiel de Java Technology Stack pour lire plus de produits secs.

Cliquez sur " Lire l'original " pour obtenir une liste complète des questions d'entrevue ~

Je suppose que tu aimes

Origine blog.csdn.net/youanyyou/article/details/108439440
conseillé
Classement