E-mails et SMS transactionnels
Les messages d'inscription, de reçu et de réinitialisation sont mis en file par l'app web et envoyés par un pool de workers.
Des files FIFO qui ne perdent pas de tâches quand un worker tombe, avec producteurs et consommateurs en parallèle.
N'importe quel service ajoute du travail sans attendre les consommateurs.
Une démonstration animée avec de vraies commandes HotKV et des exemples de réponses. Cliquez sur une étape pour y accéder directement. Les commandes et les réponses restent en anglais, exactement comme vous les saisissez et les voyez dans HotKV.
Le travail de fond, comme les e-mails, le redimensionnement d'images et les webhooks, a besoin d'une file entre le code qui le crée et celui qui l'exécute. Une file qui perd une tâche quand un worker plante en plein travail est pire que pas de file du tout, car personne ne remarque que la tâche a disparu.
Les listes vous offrent une file FIFO simple. BLMOVE déplace chaque tâche vers une liste de traitement au moment où elle est confiée à un worker, si bien qu'une tâche en cours est toujours stockée quelque part si ce worker disparaît. Producteurs et consommateurs sont servis par des threads de travail parallèles.
N'importe quel service ajoute du travail sans attendre les consommateurs.
LPUSH queue:emails "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}"BLMOVE attend qu'une tâche soit disponible, puis la déplace vers une liste de traitement en une seule étape.
BLMOVE queue:emails queue:emails:processing RIGHT LEFT 0L'e-mail est parti. La tâche est retirée de la liste de traitement.
LREM queue:emails:processing 1 "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}"Le worker 2 tombe en pleine tâche. Sa tâche est toujours dans la liste de traitement, elle n'est pas perdue.
LRANGE queue:emails:processing 0 -1Un moniteur replace la tâche abandonnée dans la file, et un autre worker la prend.
LMOVE queue:emails:processing queue:emails LEFT RIGHTLes messages d'inscription, de reçu et de réinitialisation sont mis en file par l'app web et envoyés par un pool de workers.
Les fichiers envoyés sont mis en file pour la création de miniatures et le transcodage, et un transcodeur qui plante ne perd jamais un fichier.
Les webhooks sortants sont mis en file et retentés sans bloquer la requête qui les a déclenchés.
LPUSH avec BRPOP, et les workers dorment jusqu'à l'arrivée du travail.
LPUSHBRPOPBLMOVE confie chaque tâche à une liste de traitement de façon atomique.
BLMOVELREMProducteurs et consommateurs sont servis par des threads de travail parallèles.
Pour les acquittements, les groupes de consommateurs et le rejeu, utilisez les streams.
XADDXREADGROUPSi vous prenez les tâches avec BLMOVE, la tâche reste dans la liste de traitement. Un moniteur peut replacer dans la file tout ce qui y est resté trop longtemps.
Non. BRPOP et BLMOVE attendent qu'une tâche arrive, avec un délai d'attente facultatif.
Les listes sont la file la plus simple. Les streams ajoutent les groupes de consommateurs, l'acquittement par message et l'historique. Consultez le cas d'usage du streaming d'événements.
HotKV parle le protocole Redis. Vous pouvez donc y connecter un client existant et exécuter ces mêmes commandes.