La file d'attente est une structure de données commune. Sa plus grande fonctionnalité est le premier entré, premier sorti. En tant que structure de données la plus élémentaire, la file d'attente est largement utilisée. Par exemple, faire la queue à la gare pour acheter des billets, etc. La file d'attente peut être représentée par la figure suivante :
où a1, a2 et an représentent les données dans la file d'attente. Les données sont placées dans la file d'attente à partir de la fin de la file d'attente, puis retirées de la tête de file d'attente.
Les files d'attente de messages actuellement couramment utilisées incluent ActiveMQ, RabbitMQ, Kafka, RocketMQ, Redis, etc.
Quelle est la différence entre la file d'attente des messages et la file d'attente ?
La seule différence est que lorsqu'il entre dans la file d'attente, il est appelé producteur, et lorsqu'il est retiré de la file d'attente, il est appelé consommateur.
3. Scénarios d'application de file d'attente de messages
1.1.1.1.1. Exécuté (c'est-à-dire de manière synchrone). Par exemple, dans l'exemple d'une commande dans un système de commerce électronique, la séquence d'exécution est la suivante :
Prenons le système de commerce électronique comme exemple pour expliquer. Tout d'abord, regardez l'organigramme ci-dessous :
Logique métier dans l'image ci-dessus : Le client lance une demande de création d'une application. commande, et la commande est créée. À ce moment-là, nous devons d'abord obtenir l'inventaire, puis déduire l'inventaire. De cette façon, le système de commande et le système d'inventaire forment une dépendance très étroite. Si le système d'inventaire tombe en panne à ce moment-là, parce que le système de commande dépend du système d'inventaire, le système de commande ne sera pas disponible à ce moment-là. Alors comment le résoudre ? Regardez l'organigramme d'utilisation de la file d'attente des messages ci-dessous : Dans le processus ci-dessus, nous avons ajouté la file d'attente des messages. Tout d'abord, le client lance une demande de création d'une commande et le message de commande est écrit dans la file d'attente des messages. Ensuite, le système d'inventaire s'abonne au message dans la file d'attente des messages et met enfin à jour le système d'inventaire de manière asynchrone. Si le système d'inventaire tombe en panne, puisque le système de commande ne dépend pas directement du système d'inventaire, le système de commande peut répondre normalement aux demandes des clients. Cela permet d'obtenir un découplage des applications. 1.3. Réduction des pics de traficPour les systèmes à haute concurrence, pendant les heures d'accès de pointe, un trafic soudain afflue comme une inondation vers le système d'application, en particulier certaines opérations d'écriture à haute concurrence, ce qui peut provoquer l'effondrement du serveur de base de données à tout moment. Le service ne peut pas continuer à être fourni.
L'introduction de files d'attente de messages peut réduire l'impact du trafic en rafale sur les systèmes d'application. La file d'attente de consommation est comme un « réservoir » qui intercepte les crues en amont et réduit le débit de pointe dans la rivière en aval, atteignant ainsi l'objectif de réduire les inondations catastrophiques.
L'exemple le plus courant à cet égard est le système de vente flash. Généralement, les activités de vente flash ont un trafic instantané très élevé si tout le trafic afflue vers le système de vente flash, cela submergera le système de vente flash en introduisant un message. files d'attente, le trafic en rafale peut être efficacement tamponné pour obtenir l'effet de « coupure de pointe ».
Nous utilisons le scénario de vente flash pour décrire la réduction des pics de trafic. Examinons d'abord l'organigramme ci-dessous :
ci-dessus. Dans le processus, nous désignons les services de vente flash comme des services en amont, et les services de commande, les services d'inventaire et les services de solde comme des services en aval. Le client lance une demande de vente flash. Après avoir reçu la demande du client, le service de vente flash crée une commande, modifie l'inventaire et déduit le solde. Il s'agit du scénario commercial de base de la vente flash.
Supposons que le service en aval ne puisse gérer que 1 000 requêtes simultanées en même temps, que le service en amont puisse gérer 10 000 requêtes simultanées et que le client initie 10 000 requêtes, ce qui dépasse le niveau de concurrence que le service en aval peut gérer, cela entraînera donc un temps d’arrêt des services en aval. À ce stade, vous pouvez rejoindre la file d'attente des messages pour résoudre le problème de temps d'arrêt. Regardez l'organigramme pour rejoindre la file d'attente des messages ci-dessous :
Nous avons ajouté la file d'attente des messages à l'organigramme ci-dessus pour décrire le service recevant 10 000 envoyés par le client. Une fois la demande effectuée, toutes les demandes sont écrites dans la file d'attente des messages, puis le service en aval s'abonne à la demande de vente flash dans la file d'attente des messages, puis effectue ses propres opérations de logique métier.
Prenons un exemple simple. Le service en amont peut toujours gérer 10 000 requêtes simultanées, et le service en aval ne peut toujours gérer que 1 000 requêtes simultanées. À l'heure actuelle, nous autoriserons 1 000 requêtes simultanées dans la file d'attente des messages. . demander. Le service de vente flash en amont a reçu 10 000 demandes simultanées, mais la file d'attente des messages ne peut stocker que 1 000 demandes. Les demandes excédentaires ne seront pas stockées dans la file d'attente des messages et seront directement renvoyées au client avec l'invite « Le système est occupé, veuillez. attendez!" . C’est ce qu’on appelle le scénario d’écrêtage des pointes de trafic. Ceci est déterminé par le niveau de concurrence que le service en aval peut gérer. Étant donné que le service en aval ne peut gérer que 1 000 demandes simultanées, seules 1 000 ventes flash peuvent être stockées dans la file d’attente des messages et toutes les demandes de ventes flash excédentaires seront renvoyées à l’invite du client. Cela garantit la réponse normale des services en aval, n'entraîne pas de temps d'arrêt des services en aval et améliore la disponibilité du système.
Afin de rendre le programme robuste, nous ajoutons généralement diverses fonctions de journalisation au programme, telles que comme les journaux d'erreurs, les journaux d'opérations, etc., regardez l'organigramme ci-dessous :
L'organigramme ci-dessus est le processus d'enregistrement synchrone des journaux. L'utilisation du processus de journalisation synchrone augmentera le temps consacré à l'ensemble du processus et entraînera également facilement des temps d'arrêt du système d'entreprise (si la base de données est endommagée, l'opération d'enregistrement des journaux dans la base de données provoquera une erreur). Nous pouvons utiliser des files d'attente de messages pour optimiser la transmission des journaux. Regardez l'organigramme ci-dessous :
Après avoir rejoint la file d'attente des messages, le temps passé sur le système peut être raccourci et la fonction de découplage du système d'application peut également être atteint.
La fonction principale de la file d'attente des messages est d'envoyer et de recevoir des messages. Elle dispose d'un mécanisme de communication efficace. à l'intérieur, il est donc très approprié pour la messagerie.
Nous pouvons développer un système de chat point à point basé sur des files d'attente de messages, ou nous pouvons développer un système de diffusion pour diffuser des messages à un grand nombre de destinataires.
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!