Dois-je utiliser la file d'attente des messages ? Parlons des raisons pour lesquelles nous devrions l'utiliser

Cet article vous apporte des connaissances pertinentes sur les files d'attente de messages. Il présente principalement les raisons pour lesquelles nous utilisons les files d'attente de messages et pourquoi nous devrions utiliser les files d'attente de messages. Amis intéressés, jetons-y un coup d'œil ensemble, j'espère que cela vous sera utile. . Tout le monde est utile.

Pourquoi utiliser les files d'attente de messages ? Résumé en six mots : découplage, asynchrone, élimination des pics

1) Découplage

Le couplage entre les systèmes en mode traditionnel est trop fort. Comment le dire, par exemple : le système A envoie des données à trois systèmes B, C et D via des appels d'interface. Si le système E est connecté à l'avenir ou si le système B n'a pas besoin d'être connecté, le système A devra également être modifié. le code, ce qui est très gênant.

Si le système A génère une donnée relativement critique, alors il doit toujours réfléchir à ce qu'il faut faire si les quatre systèmes B, C, D et E échouent ? Ont-ils tous reçu ces données ? De toute évidence, le système A est fortement couplé à d’autres systèmes.

Et si nous écrivons des données (message) dans la file d'attente des messages, le système qui a besoin du message le consomme directement à partir de la file d'attente des messages elle-même. De cette façon, le système A n'a pas besoin de se demander à qui envoyer les données, ni de conserver ce code, ni de se demander si d'autres systèmes sont appelés avec succès, un délai d'expiration en cas d'échec, etc. Quoi qu'il en soit, je suis seul responsable pour la production, et je ne me soucie de rien d'autre.

2) Asynchrone

Regardons d'abord la situation de synchronisation traditionnelle. Par exemple : le système A reçoit une demande d'utilisateur et doit effectuer une opération d'écriture de bibliothèque, et la même chose doit être faite dans B, C et D. Effectuer des opérations d’écriture de bibliothèque dans le système. Si A écrit la bibliothèque localement, cela ne prend que 1 ms, tandis que les trois systèmes B, C et D prennent respectivement 100 ms, 200 ms et 300 ms. Le délai total final de la requête est de 1 + 100 + 200 + 300 = 601 ms, ce qui réduit considérablement l'expérience utilisateur.

Si vous utilisez la file d'attente des messages, le système A n'a besoin que d'envoyer 3 messages à la file d'attente des messages. Si cela prend 5 ms, le temps total entre l'acceptation d'une demande par le système A et le retour d'une réponse à l'utilisateur est de 1. + 5 = 6 ms Pour les utilisateurs, la satisfaction de l'expérience est directement maximisée.

3)Élimination des pics

Si aucun cache ou file d'attente de messages n'est utilisé, alors le système est directement basé sur la base de données MySQL. S'il y a une telle période de pointe, un grand nombre de requêtes sont générées et. versé dans MySQL Il ne fait aucun doute que le système va planter directement.

Ensuite, si nous utilisons la file d'attente de messages, supposons que MySQL peut traiter jusqu'à 1 000 éléments de données par seconde et que 5 000 éléments de données sont versés instantanément pendant la période de pointe. Cependant, ces 5 000 éléments de données sont versés dans le message. file d'attente. De cette manière, notre système peut extraire lentement les requêtes de la file d'attente des messages en fonction des capacités de la base de données et ne pas dépasser le nombre maximum de requêtes qu'il peut traiter par seconde.

C'est-à-dire que 5 000 requêtes arrivent et 1 000 requêtes sortent de la file d'attente des messages par seconde. En supposant que la période de pointe est d'une heure, il peut y avoir des centaines de milliers, voire des millions de requêtes en retard dans la file d'attente des messages pendant cette période. période. Cependant, ce retard de pointe à court terme est tout à fait acceptable, car après la période de pointe, il n'y aura plus autant de requêtes entrant dans la file d'attente de messages par seconde, mais la base de données les traitera toujours à un rythme de 1 000 requêtes par seconde. Ainsi, dès que la période de pointe est passée, le système traitera rapidement l’arriéré de messages.

Apprentissage recommandé : "Tutoriel vidéo Redis"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!