Quels sont les scénarios d'application de la file d'attente de messages Java ?

1. Qu'est-ce qu'une file d'attente

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.

2. Qu'est-ce qu'une file d'attente de messages ? Message Queue (Message Queue) est un conteneur de messages distribué qui utilise une file d'attente (Queue) comme structure de données de stockage sous-jacente et peut également être utilisé pour résoudre la communication entre différents processus et applications. Appelé middleware de messages.

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

Les scénarios d'application de file d'attente de messages sont très larges. Ci-dessous, nous énumérons certains des scénarios les plus courants

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 :

L'utilisateur soumet la commande. Les points seront ajoutés une fois la commande terminée. Notification par SMS des changements de points.

peut être représenté par l'organigramme suivant :

S'il est exécuté dans l'ordre ci-dessus, si chaque service prend une seconde, alors le client y passera 3 secondes. Pour les utilisateurs, 3 secondes sont évidemment intolérables, alors comment résoudre ce problème ? Nous pouvons utiliser une méthode asynchrone pour résoudre ce problème. Regardez l'organigramme ci-dessous :

De cette façon, le service de points et le service SMS utilisent des opérations asynchrones de thread, le client n'a alors qu'à y consacrer 1 seconde. prendra du temps à terminer. Cependant, cette approche asynchrone entraînera un autre problème : une concurrence réduite. Étant donné que le service de points et le service SMS doivent ouvrir des threads dans le service de commande, l'ouverture de davantage de threads entraînera l'accès simultané du client au service de commande, ce qui peut faire en sorte que le temps réel nécessaire au client pour soumettre une commande dépasse 1 seconde. Alors, comment résoudre les problèmes causés par l’asynchrone ? C'est-à-dire pour utiliser la file d'attente des messages, voir l'organigramme ci-dessous :

Dans le processus ci-dessus, nous avons ajouté le rôle d'une file d'attente de messages. Tout d'abord, le client soumet la commande, puis écrit la commande dans le message. file d'attente, service de points Consommer les messages dans la file d'attente des messages en même temps que le service SMS. Cette méthode ne nécessite pas que le service de commande ouvre un thread asynchrone supplémentaire, et le client peut atteindre une consommation en temps réel de 1 seconde.

1.2. Découplage d'application

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 trafic

Pour 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.

2. Scénario de journalisation

Optimiser la transmission des journaux

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.

3. Scénario de communication instantanée

Chatroom

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!