Implémentation et application de la file d'attente de messages PHP

Comme nous le savons tous, lors de la conception d'un site Web, vous rencontrerez des « messages texte en masse » aux utilisateurs, « un grand nombre de journaux dans le système de commande », une « conception de vente flash », etc. Le serveur ne peut pas gérer cela soudainement explosion de pression. Dans cette situation Pour assurer l'utilisation normale et efficace du système, l'aide de la « file d'attente des messages » est nécessaire. 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

@ Cas de réduction des pics de trafic : le type de liste de Redis réalise une vente flash

@RabbitMQ : Une solution de mise en œuvre de système de messagerie plus professionnelle

Comprendre la file d'attente des messages

1.

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, et n'a pas besoin d'être traité immédiatement par le système. De plus, il y aura un programme qui lit les données et les traite une par une en séquence.

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 tri : certains scénarios doivent être traités dans l'ordre des produits, comme l'entrée et la sortie uniques 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 courants de la mise en œuvre des files d'attente

Médias de file d'attente

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

2, mise en cache, telle 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, un mécanisme de déclenchement de traitement actuellement 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)

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

2 Cas de découplage : Traitement des files d'attente "Système de commande" et "Système de distribution" Parlons brièvement du découplage des programmes :

Le découplage des programmes consiste à éviter le problème de savoir qui doit être secouru en premier lorsque votre femme et votre mère tombent à l'eau en même temps

(en riant) Pour les commandes Pour le processus, 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 nos achats en ligne. Je passe une commande, je vois ma marchandise en arrière-plan. À 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 distribution, 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 lit la table de file d'attente pour 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 réduction des pics de trafic : le type de liste de Redis réalise une vente flash

redis Basé sur la mémoire, il 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'aura donc pas à s'inquiéter des coupures de courant. 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é)

De manière générale, faire des ventes 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 Type de liste dans le type de données Redis

La liste de 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 données stockées dans Redis sont traitées 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 des messages au canal de message

3. Traitement du consommateur message

File d'attente des travaux

　

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

Ce n'est pas seulement cela résout le découplage entre producteurs et consommateurs, mais peut également réaliser 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. Cas de découplage et cas d'écrêtage de pointe, ainsi que 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.

D'après ce que j'ai compris, 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 l'autre est synchrone. serveur de messages Utiliser un mode asynchrone non bloquant.

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

Support de file d'attente :

Mysql : haute fiabilité, facile à mettre en œuvre, vitesse lente
Redis : vitesse rapide, message volumineux unique package Faible efficacité en termes de temps
Système de messagerie : hautement professionnel, fiable, coût d'apprentissage élevé (par exemple : RabbtiMQ)

Mécanisme de déclenchement pour le traitement des messages :

Lecture en boucle infinie : facile à mettre en œuvre, Impossible de récupérer à temps lorsqu'un défaut survient ;
Tâches planifiées : la pression est uniformément répartie et il existe une limite supérieure à la capacité de traitement. (Le plus gros défaut : l'intervalle de temps entre les tâches de positionnement et les données traitées doivent être saisis avec précision. La tâche suivante ne peut pas être considérée comme ayant été démarrée avant que la tâche précédente ne soit terminée)

Processus démon : similaire à PHP -FPM et PHP-CGI, une connaissance du shell est requise

Recommandations associées :

Implémentation PHP du partage d'instances de classe de file d'attente de messages

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!