data / redis

Pub/Sub : messagerie en temps réel

Leçon 71 exercice

Explication

Ce que vous allez apprendre

Publier un message sur un canal et l'écouter depuis un ou plusieurs abonnés
Utiliser PSUBSCRIBE pour s'abonner à un motif de canaux plutôt qu'à un canal fixe
Comprendre pourquoi le Pub/Sub Redis est un mécanisme "fire-and-forget"
Identifier les limites structurelles du Pub/Sub (pas de persistance, pas d'accusé de réception)
Savoir quand préférer les Streams à la place du Pub/Sub classique

Dans quel contexte ?

Une application affiche des notifications en temps réel : dès qu'un événement métier survient côté serveur (une commande expédiée, un nouveau message reçu), tous les clients connectés et concernés doivent être informés immédiatement, sans qu'ils aient besoin de reposer une requête en boucle. Le Pub/Sub Redis répond exactement à ce besoin de diffusion instantanée.

D'abord, le principe est d'une simplicité trompeuse

Un client s'abonne à un canal nommé (SUBSCRIBE notifications), un autre publie un message sur ce même canal (PUBLISH notifications "Nouveau message reçu"). Tous les abonnés présents au moment de la publication reçoivent le message quasi instantanément — c'est tout le mécanisme, sans aucune configuration supplémentaire.

Une fois cette base comprise, un besoin plus flexible apparaît vite

S'abonner à un canal fixe par utilisateur (user:42:events) obligerait à connaître à l'avance chaque canal exact. PSUBSCRIBE user:*:events permet de s'abonner à un motif, recevant tout message publié sur n'importe quel canal qui correspond au pattern — beaucoup plus flexible pour un serveur qui gère un grand nombre d'utilisateurs sans connaître leurs identifiants à l'avance.

Commande	Abonnement	Cas d'usage
`SUBSCRIBE canal`	Un canal exact	Notification globale sur un sujet fixe
`PSUBSCRIBE motif`	Tous les canaux matchant un motif	Notifications par utilisateur, sans canal fixe connu à l'avance

Il reste une limitation structurelle essentielle à comprendre avant d'adopter ce mécanisme

Le Pub/Sub Redis ne conserve absolument rien : c'est un mécanisme "fire-and-forget" (envoyer et oublier). Si un abonné est déconnecté au moment où un message est publié, il ne le recevra jamais, et il n'existe aucun moyen de rejouer les messages manqués après coup.

Piège fréquent

Utiliser le Pub/Sub classique pour une messagerie qui doit être fiable (des transactions financières, des commandes à traiter absolument) est une erreur de conception : sans persistance ni accusé de réception, tout message publié pendant une déconnexion, même brève, est perdu définitivement, sans logging ni alerte automatique de cette perte.

Prérequis

Cette leçon suppose que tu es à l'aise avec les commandes de base et la connexion à Redis (leçons précédentes) : le Pub/Sub utilise une connexion dédiée, différente du mode de commande habituel — une fois abonné, le client ne peut plus utiliser cette même connexion pour exécuter d'autres commandes.

Ensuite, une alternative existe pour les besoins de fiabilité

Quand la persistance et la relecture sont indispensables — un log d'événements qu'on doit pouvoir rejouer, plusieurs workers qui doivent se partager le traitement sans jamais retraiter le même message deux fois — les Redis Streams, abordés dans une leçon dédiée plus loin dans ce cours, offrent ces garanties que le Pub/Sub classique ne peut structurellement pas fournir.

Bonne pratique

Réserve le Pub/Sub classique à des cas où la perte occasionnelle d'un message est acceptable : une notification d'interface utilisateur ("un nouvel élément est arrivé, rafraîchis ta vue"), où l'utilisateur peut de toute façon recharger la donnée manuellement si besoin.

Maintenant que tu sais diffuser des messages en temps réel, la prochaine leçon aborde un besoin très différent : garantir qu'un lot de commandes s'exécute de façon atomique et isolée, avec MULTI/EXEC et WATCH.

Commandes & code

Pub/Sub : messagerie en temps réel

# Terminal 1 : s'abonner à un ou plusieurs canaux
SUBSCRIBE notifications
SUBSCRIBE canal1 canal2 canal3               # plusieurs canaux à la fois

# Abonnement par motif (pattern) : reçoit tout ce qui matche "user:*:events"
PSUBSCRIBE user:*:events

# Terminal 2 : publier un message (tous les abonnés le reçoivent, immédiatement)
PUBLISH notifications "Nouveau message reçu"
PUBLISH user:42:events "login"

# Voir les canaux actifs et le nombre d'abonnés
PUBSUB CHANNELS
PUBSUB CHANNELS "user:*"                     # filtré par motif
PUBSUB NUMSUB notifications                  # nombre d'abonnés sur ce canal

# Se désabonner
UNSUBSCRIBE notifications
PUNSUBSCRIBE user:*:events

import redis
import threading

r = redis.Redis(decode_responses=True)

def subscriber():
    pubsub = r.pubsub()
    pubsub.subscribe("notifications")
    for message in pubsub.listen():           # bloque, itère sur chaque message reçu
        if message["type"] != "message":
            continue                          # ignore les messages de type "subscribe"
        print("reçu:", message["data"])

def publisher():
    r.publish("notifications", "Événement important")

threading.Thread(target=subscriber, daemon=True).start()

# LIMITES IMPORTANTES du Pub/Sub Redis classique :
# - Pas de persistance : un abonné déconnecté RATE tous les messages publiés entre-temps
# - Pas d'accusé de réception, pas de replay
# - Pour de la messagerie durable/rejouable -> utiliser les Redis Streams (leçon dédiée)

Résumé

Le Pub/Sub Redis est du "fire-and-forget" : aucun historique, aucune garantie de livraison.
PSUBSCRIBE permet de s'abonner à des motifs de canaux plutôt qu'à un canal fixe.
Pour de la messagerie fiable et rejouable, préférer les Streams (XADD/XREAD) plutôt que Pub/Sub.

Exercices pratiques

1 disponible

Mission : expliquer pourquoi des notifications ont disparu pendant une coupure réseau

Objectif : Diagnostiquer une perte de notifications liée aux limites structurelles du Pub/Sub, et mettre en place un abonnement par motif adapté à un grand nombre d'utilisateurs.

Contexte

Plusieurs utilisateurs se plaignent d'avoir raté des notifications pendant une brève coupure de connexion. L'équipe backend veut aussi arrêter de coder en dur un canal par utilisateur, et se demande si le Pub/Sub peut un jour garantir zéro perte. Tu dois clarifier ce que le Pub/Sub peut et ne peut pas faire, et proposer un abonnement adapté à un grand nombre d'utilisateurs.

Résoudre l’exercice →