Introduction détaillée aux concepts, principes et scénarios d'utilisation des files d'attente de messages (avec cas)

Comme nous le savons tous, lors de la conception d'un site Web, vous rencontrerez des "messages texte de groupe" aux utilisateurs, "un grand nombre de journaux dans le système de commande", une "conception de vente flash" , etc. Le serveur ne peut pas les gérer. Ce type d'explosion de pression instantanée nécessite l'aide d'une « file d'attente de messages » pour garantir l'utilisation normale et efficace du système. Cet article étudie principalement à travers l'idée de file d'attente de messages.

Comprendre principalement les connaissances suivantes :

　1. Qu'est-ce qu'une file d'attente et que peut-elle faire ?

2. Quels sont les scénarios d'application de l'alignement ?

3. Comment utiliser les files d'attente pour découpler les services ?

4. Comment utiliser la file d'attente Redis pour éliminer la haute pression ?

5. Comment utiliser le système d'alignement professionnel RabbitMQ ?

Le contenu principal est résumé comme suit

　@Concepts, principes et scénarios de file d'attente de messages

　@Cas de découplage : système de commande de traitement de file d'attente et système de distribution

@Traffic Peak Shaving Case : le type de liste Redis réalise des ventes flash

@RabbitMQ : Un plan de mise en œuvre d'un système de messagerie plus professionnel

1. Comprendre le file d'attente de messages

1.1 Concept de file d'attente de messages

Essentiellement, la file d'attente de messages est un middleware avec une structure de file d'attente, ce qui signifie que le message peut être renvoyé directement après avoir été placé dans ce middleware. le système n'a pas besoin de les traiter immédiatement, mais un autre programme lira les données et les traitera une par une dans l'ordre.

C'est-à-dire que lorsque vous rencontrez une situation où la concurrence est particulièrement importante et prend beaucoup de temps, et que vous n'avez pas besoin de renvoyer les résultats du traitement immédiatement, l'utilisation de files d'attente de messages peut résoudre de tels problèmes.

1.2 Structure de base

Mettez la file d'attente par un système d'entreprise, insérez le message dans la file d'attente des messages un par un et renvoyez directement le résultat réussi après l'insertion est réussie. Il y aura un système de traitement de messages à l'avenir, qui supprimera et traitera les enregistrements dans le système de messagerie un par un, complétant ainsi un processus de retrait de la file d'attente.

1.3 Scénarios d'application

Redondance des données : par exemple, le système de commande nécessite une conversion et un enregistrement stricts des données à l'avenir. La file d'attente des messages peut stocker ces données de manière persistante dans la file d'attente, puis il y en a. commandes , le programme de traitement ultérieur l'obtient et une fois le traitement ultérieur terminé, cet enregistrement est supprimé pour garantir que chaque enregistrement peut être traité.

Découplage du système : après avoir utilisé le système de messagerie, le système de mise en file d'attente et le système de sortie de file d'attente sont séparés, ce qui signifie que tant qu'il plante un jour, cela n'affectera pas le fonctionnement normal de l'autre système.

Réduction des pics de trafic : par exemple, pour les ventes flash et les ventes urgentes, nous pouvons utiliser des files d'attente de messages en conjonction avec la mise en cache, ce qui peut résister efficacement au nombre de visites instantanées et empêcher le serveur d'être submergé et de provoquer un crash.

Communication asynchrone : le message lui-même peut être renvoyé directement après avoir été mis en file d'attente.

Évolutivité : par exemple, la file d'attente des commandes peut non seulement traiter les commandes, mais peut également être utilisée par d'autres entreprises.

Garantie de séquençage : certains scénarios doivent être traités dans l'ordre des produits, comme l'entrée unique et la sortie unique pour garantir que les données sont traitées dans un certain ordre. Il est possible d'utiliser des files d'attente de messages.

Les scénarios ci-dessus sont des scénarios d'utilisation courants de la file d'attente de messages. Bien entendu, la file d'attente de messages n'est qu'un middleware et peut être utilisée conjointement avec d'autres produits.

1.4 Avantages et inconvénients des implémentations de files d'attente courantes

Médias de file d'attente

1 Base de données, telle que MySQL (haute fiabilité, facile à mettre en œuvre, lente)

2, cache, tel que Redis (rapide, faible efficacité lorsqu'un seul paquet de messages est trop volumineux)

3. Système de messagerie, tel que RabbitMq (très professionnel, fiable, coût d'apprentissage élevé)

Mécanisme de déclenchement du traitement des messages

1. Lecture en boucle sans fin : facile à mettre en œuvre, impossible de récupérer à temps en cas de panne (plus adapté à la vente flash, fonctionnement et maintenance plus centralisés)

2. Tâches planifiées : la pression est uniformément répartie, avec une limite supérieure de traitement actuellement un mécanisme de déclenchement de traitement populaire ; (Le seul inconvénient est que vous devez faire attention à l'intervalle et aux données. N'attendez pas que la tâche précédente ne soit pas terminée et que la tâche suivante recommence)

Processus démon : similaire à php-. fpm et php-cg, nécessite les bases du shell

2. Cas de découplage : traitement de la file d'attente "Système de commande" et "Système de distribution"

Pour le processus de commande, nous pouvons concevoir deux systèmes, l'un est le « système de commande » et l'autre est le « système de livraison ». Nous aurions tous dû le voir lors de mes achats en ligne. je peux voir en arrière-plan que mes marchandises sont livrées au milieu. À l’heure actuelle, un « système de prestation » doit être impliqué.

Si nous concevons ensemble le « système de commande » et le « système de livraison » lors de la réalisation de l'architecture, il y aura quelques problèmes. Tout d'abord, pour le système de commande, la pression sur le système sera relativement élevée, mais « le système de distribution » ne doit pas nécessairement réagir immédiatement à ces pressions.

Deuxièmement, nous ne voulons pas que la défaillance du système de commande entraîne une défaillance du système de livraison, ce qui affecterait le fonctionnement normal des deux systèmes en même temps. Nous espérons donc découpler ces deux systèmes. Une fois les deux systèmes séparés, nous pouvons communiquer entre les deux systèmes via une « table de file d'attente » intermédiaire.

2.1 Conception de l'architecture

1. Tout d'abord, le système de commande recevra la commande de l'utilisateur, puis traitera la commande.

2. Ces informations de commande seront ensuite écrites dans la table de file d'attente. Cette table de file d'attente est la clé de la communication entre les deux systèmes.

3. Un programme exécuté régulièrement par le système de distribution pour lire la table de file d'attente pour le traitement.

4. Après traitement par le système de distribution, les enregistrements traités seront marqués.

2.2 Déroulement du programme

3. Cas de rasage des pics de trafic : le type de liste de Redis implémente des ventes flash

redis Basé sur la mémoire, sa vitesse sera très rapide. Redis est un très bon complément à la base de données car il est durable. Redis écrira périodiquement des données sur le disque dur, il n'a donc pas à s'inquiéter des pannes de courant. , il a plus d'avantages qu'un autre cache memcache De plus, redis fournit cinq types de données (chaîne, liste doublement chaînée, hachage, ensemble, ensemble ordonné)

En général, c'est une vente flash Redis est un bon. choix pour les cas où les cas, les achats urgents et les cas nécessitant une file d'attente sont instantanément plus élevés que les vôtres.

3.1 Le type de liste dans le type de données redis

La liste dans redis est une liste doublement chaînée, et les données peuvent être ajoutées à partir de la tête ou de la queue.

* LPUSH/LPUSHX : Insérez la valeur dans la tête de la liste (/existante)

* RPUSH/RPUSHX : Insérez la valeur dans la queue de la liste (/existante)

* LPOP : Supprimer et obtenir le premier élément de la liste

* RPOP : Supprimer et obtenir le dernier élément de la liste

* LTRIM : Conserver les éléments dans la plage spécifiée

* LLEN : Obtenez la longueur de la liste

* LSET : Définissez la valeur de l'élément de la liste par index

* LINDEX : Récupérez l'élément de la liste par index

* LRANGE : obtenez les éléments dans la plage spécifiée de la liste

3.2 Conception de l'architecture

Une conception de programme Flash Kill à structure simple.

1. Enregistrez d'abord quel utilisateur a participé à la vente flash et enregistrez son temps.

2. Enregistrez l'ID de l'utilisateur dans la liste Redis et laissez-le mettre en file d'attente. S'il est stipulé que seuls les 10 premiers utilisateurs peuvent participer avec succès, si le nombre dans la liste est suffisant, il ne sera pas autorisé à continuer à ajouter des données. De cette façon, la longueur de la liste Redis ne sera que de 10

3 Enfin, écrivez lentement les données en Redis dans la base de données pour réduire la pression sur les données

3.3 Au niveau du code. conception

1. Lorsque l'utilisateur démarre la vente flash, écrivez la demande du programme de vente flash dans Redis (uid, time_stamp).

2. S'il est stipulé que seules 10 personnes peuvent réussir la vente flash, vérifiez la longueur des données stockées dans Redis. Si elle dépasse la limite supérieure et supprimez-la directement, cela signifie que la vente flash est terminée. complété.

3. Enfin, les 10 éléments de données stockés dans Redis sont traités dans une boucle infinie, puis les données sont lentement récupérées et stockées dans la base de données MySQL.

La zone de vente flash met beaucoup de pression sur la base de données. Si nous n'avons pas une telle conception, cela provoquera un goulot d'étranglement en écriture dans MySQL. Nous utilisons une liste de files d'attente dans Redis, puis plaçons la demande de vente flash dans Redis. Enfin, nous écrivons lentement les données dans la base de données via le programme d'entreposage, de cette façon, le trafic peut être équilibré et il n'y aura aucun impact sur MySQL. . Trop de pression.

4. RabbitMQ

Nous expliquons ici quelques utilisations de RabbitMQ Tout d'abord, lorsque nous avons parlé du cas de la vente flash auparavant, nous avons mentionné le mécanisme de verrouillage pour empêcher. d'autres programmes ne traitent pas le même enregistrement. Si notre architecture système est très complexe, il existe plusieurs programmes lisant une file d'attente en temps réel, ou j'ai plusieurs programmes d'envoi qui exploitent une ou plusieurs files d'attente en même temps, et je veux même ces programmes. à distribuer sur différentes machines dans ce cas, l'utilisation de la file d'attente Redis est quelque peu inadéquate. Que faire à ce stade ? Nous devons introduire des systèmes de file d'attente de messages plus professionnels, qui peuvent mieux résoudre le problème.

4.1 Architecture et principes de RabbitMQ

Caractéristiques : Implémentation complète d'AMQP, simplification du cluster, persistance, multiplateforme

Utilisation de RabbitMQS

1. Installation de RabbitMQ (rabbitmq-server, php-amqplib)

2. Le producteur envoie un message au canal de message

3. File d'attente de travail

Idée : le producteur l'envoie au système de messagerie, et le système de messagerie encapsule la tâche dans une file d'attente de messages, puis utilise la même file d'attente pour plusieurs consommateurs

Cela résout non seulement le découplage entre producteurs et consommateurs, mais permet également le partage des consommateurs et des tâches, réduisant ainsi la pression sur le serveur.

5. Résumé

Ce qui précède se concentre principalement sur l'apprentissage des concepts, des principes et des scénarios des files d'attente de messages. Découplage des cas et compréhension de l'utilisation simple de RabbitMQ.

6. Question

Quelle est la plus grande différence entre Redis et la sélection du serveur de messages.

Je crois comprendre que Redis traite les requêtes une par une. Redis est un seul thread. Il est différent de l'implémentation des IO du serveur de messages. L'un est synchrone et l'autre est asynchrone, tandis que Redis utilise le blocage synchrone, tandis que le serveur de messages IO est synchrone. serveur de messages Utiliser un mode asynchrone non bloquant.

Pour plus de connaissances sur Redis, veuillez visiter la colonne Tutoriel d'utilisation de 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!