Comment implémenter une file d'attente de messages basée sur Redis

La file d'attente de messages, Message Queue, est souvent utilisée pour résoudre les problèmes de cohérence des ressources dans les systèmes concurrents, améliorer les capacités de traitement de pointe et garantir l'ordre, la récupérabilité et la livraison obligatoire des propriétés des messages. , découplage d'applications ou mise en œuvre d'une communication asynchrone, etc. (Apprentissage recommandé : Tutoriel vidéo Redis)

Il existe de nombreuses applications MQ sur le marché (par exemple : Kafka, RabbitMQ, Disque), et elles peuvent également être implémentées sur la base de Redis, qui est plus typique. Les solutions incluent :

Implémentation basée sur des listes de LPUSH+BRPOP

PUB/SUB, mode abonnement/publication

Sorted-Set -implémentation basée sur

Implémentation basée sur le type de flux

Dans l'utilisation des files d'attente de messages, il y a des producteurs et des consommateurs. Les producteurs sont responsables de la génération des messages et les consommateurs sont responsables du traitement des messages.

La production fait référence au fait de placer des messages dans la file d'attente des messages.

La consommation fait référence à la lecture et au traitement des messages. Habituellement, une fois qu'un message est consommé, il doit être supprimé de la file d'attente des messages.

Implémentation de LPUSH+BRPOP basée sur List

La commande typique est :

LPUSH，将消息队列
BRPOP，从队列中取出消息，阻塞模式

est une solution typique basée sur la file d'attente FIFL. Parmi eux, LPUSH est ce que fait le producteur et BRPOP est ce que fait le consommateur.

Ce mode présente de nombreux avantages :

Mise en œuvre simple

Reids prend en charge les messages persistants, ce qui signifie que les messages ne seront pas perdus et pourront être consultés à plusieurs reprises (note Ne pas consommer, juste regarder et utiliser, consignes du cours LRANGE).

L'ordre peut être assuré. Utilisez la commande LPUSH pour garantir l'ordre des messages

En utilisant RPUSH, le message peut être placé au début de la file d'attente pour atteindre l'objectif de priorisation des messages. et réaliser des messages simples.

En même temps, il y a certains inconvénients :

Il est plus difficile de faire une confirmation de consommation ACK, c'est-à-dire qu'il n'y a aucune garantie que le consommateur aura problèmes de temps d'arrêt non traités après la lecture. entraînant une perte inattendue de messages. Habituellement, vous devez gérer vous-même une liste en attente pour vous assurer que le message est traité et confirmé.

Impossible d'utiliser le mode diffusion, tel que le mode Pub/Discribe typique.

Ne peut pas être consommé à plusieurs reprises, une fois consommé, il sera supprimé

La consommation de groupe n'est pas prise en charge et doit être résolue par vous-même au niveau de la couche logique métier

PUB /SUB, modèle d'abonnement/édition

SUBSCRIBE，用于订阅信道
PUBLISH，向信道发送消息
UNSUBSCRIBE，取消订阅

Les producteurs et les consommateurs interagissent via le même canal (Channel). Un canal est en réalité une file d'attente. Il y a généralement plusieurs consommateurs. Plusieurs consommateurs s'abonnent à la même chaîne Lorsqu'un producteur publie un message sur la chaîne, la chaîne publiera immédiatement le message à chaque consommateur un par un. On voit que le canal est un canal divergent pour les consommateurs et que chaque consommateur peut recevoir le même message. Relation typique un-à-plusieurs.

Les avantages typiques sont :

Mode de diffusion typique, un message peut être publié à plusieurs consommateurs

Abonnement multicanal, les consommateurs peuvent s'abonner à plusieurs chaînes en même temps pour recevoir plusieurs types de messages

Les messages sont envoyés instantanément et les messages n'ont pas besoin d'attendre que les consommateurs les lisent. Les consommateurs recevront automatiquement les messages publiés par la chaîne

. Il y a aussi quelques inconvénients :

Une fois le message publié, il ne peut pas être reçu. Autrement dit, si le client n'est pas en ligne au moment de la publication, le message sera perdu et ne pourra pas être récupéré

Il n'y a aucune garantie que l'heure reçue par chaque consommateur soit cohérente

Si un message apparaît sur le client consommateur. L'arriéré, dans une certaine mesure, sera déconnecté de force, entraînant une perte inattendue de messages. Cela se produit généralement lorsque la production de messages est beaucoup plus rapide que la vitesse de consommation

On peut voir que le mode Pub/Sub n'est pas adapté aux services de stockage de messages et de backlog de messages, mais est bon pour traiter la diffusion, l'instantané messagerie et services de commentaires instantanés.

Implémentation basée sur l'ensemble ordonné SortedSet

ZADD KEY score member，压入集合
ZRANGEBYSCORE，依据score获取成员

La solution de l'ensemble ordonné est plus couramment utilisée pour déterminer l'ID du message par vous-même, en utilisant le score du membre de l'ensemble comme l'ID du message, garantit l'ordre et peut également assurer l'augmentation monotone de l'ID du message. Habituellement, la solution horodatage + numéro de séquence peut être utilisée. L'augmentation monotone de l'ID du message est assurée et une file d'attente de messages ordonnée peut être créée en utilisant la fonctionnalité de tri de SortedSet selon le score.

Par rapport à la solution ci-dessus, l'avantage est que l'ID du message peut être personnalisé, ce qui est plus important lorsque l'ID du message est significatif. Les inconvénients sont également évidents. Les messages en double ne sont pas autorisés (pensez qu'il s'agit d'une collection). En même temps, des erreurs dans la détermination de l'ID du message entraîneront un ordre erroné des messages.

Donc, si vous n'avez pas besoin de personnaliser l'ID du message, cette solution semble un peu inutile...

Implémentation basée sur le type de Stream

Ce redis de type Stream est destiné à implémenter la file d'attente de messages. Prend en charge la génération automatique d'ID de message, la consommation de groupe, l'ACK, le transfert de messages, la surveillance de file d'attente et d'autres fonctions principales de file d'attente de messages

Pour plus d'articles techniques liés à Redis, veuillez visiter le Tutoriel de démarrage de Redis rubrique pour apprendre !

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!