Les notifications d'espace de clés permettent aux clients de s'abonner (via Pub/Sub) à des événements concernant les modifications de clés — comme une clé définie, supprimée ou expirée. Elles permettent de réagir aux changements de données dans Redis, l'événement d'expiration étant un déclencheur particulièrement courant et utile.
CONFIG SET notify-keyspace-events KEA
PSUBSCRIBE
PSUBSCRIBE
Vous activez les notifications (notify-keyspace-events, en choisissant quels événements) et vous vous abonnez à des canaux spéciaux : __keyevent@<db>__:<event> (événements d'un type, par exemple expired, avec la clé affectée) ou __keyspace@<db>__:<key> (événements sur une clé spécifique).
The "expired" event is widely used as a TIMER/SCHEDULER:
→ set a key with a TTL; when it expires, you get notified → trigger an action
→ e.g. "order:123:hold" expires in 15 min → notification → release the held inventory
→ delayed jobs, session-expiry handling, scheduled actions without a separate scheduler
⚠️ Built on PUB/SUB → fire-and-forget: if no subscriber is connected when the event
fires, it's MISSED (not reliable/persistent). Don't rely on it for critical events.
⚠️ "expired" fires when the key is actually REMOVED (lazy/active expiration), which can
LAG behind the exact TTL time → not precise timing.
⚠️ Has overhead at high volume; for reliable event handling, use STREAMS instead.
Comprendre les notifications d'espace de clés est une connaissance utile pour réagir aux changements de données dans Redis, une capacité qui active certains motifs pilotés par événements — bien que comprendre ses limitations soit tout aussi important.
Cette fonctionnalité permet aux clients de s'abonner à des événements concernant les modifications de clés (définitions, suppressions et surtout expirations) via Pub/Sub, permettant à Redis de notifier l'application lorsque les données changent.
L'événement d'expiration en particulier alimente un motif courant et élégant : utiliser la TTL d'une clé comme minuteur/ordonnanceur — définir une clé pour expirer après un délai, et la notification d'expiration déclenche une action (libération d'inventaire réservé après une période de rétention, gestion de l'expiration de session, exécution de tâches différées), fournissant un comportement d'action planifiée sans système d'ordonnancement séparé.
Comprendre comment activer les notifications (notify-keyspace-events) et s'abonner aux canaux spéciaux keyevent/keyspace est le mécanisme pratique.
Critiquement, comprendre les avertissements est essentiel pour utiliser cela correctement : parce qu'il est construit sur Pub/Sub, c'est du tir et oubli (les événements sans abonné connecté sont définitivement manqués — donc c'est peu fiable pour les événements critiques), l'événement d'expiration a du retard par rapport à la TTL exacte (se déclenche lorsque la clé est réellement supprimée par expiration paresseuse/active, donc le timing n'est pas précis), et cela a une surcharge à grand volume — signifiant que pour la gestion fiable des événements, Streams ou un autre mécanisme est préférable.
Cette conscience prévient une dépendance excessive aux notifications pour la garantie de livraison.
Puisque réagir aux changements de données Redis (surtout les expirations comme minuteurs) est un motif utile pour les actions différées et l'ordonnancement, et puisque les notifications d'espace de clés le fournissent mais avec d'importantes limitations de fiabilité et de timing (héritant de la nature tir et oubli de Pub/Sub), comprendre les notifications d'espace de clés — ce qu'elles sont, le motif d'expiration comme minuteur, et surtout les avertissements — est une connaissance précieuse et pratiquement pertinente pour utiliser cette fonctionnalité de manière appropriée tout en sachant quand ses limitations exigent une approche plus fiable.