Keyspace-Benachrichtigungen ermöglichen es Clients, sich (über Pub/Sub) auf Ereignisse über Änderungen an Keys zu abonnieren — wie das Setzen, Löschen oder Ablaufen eines Keys. Sie ermöglichen es, auf Datenänderungen in Redis zu reagieren, wobei das Ablaufereignis ein besonders häufiger und nützlicher Auslöser ist.
CONFIG SET notify-keyspace-events KEA
PSUBSCRIBE
PSUBSCRIBE
Sie aktivieren Benachrichtigungen (notify-keyspace-events, wählen Sie, welche Ereignisse) und abonnieren spezielle Kanäle: __keyevent@<db>__:<event> (Ereignisse eines Typs, z. B. expired, mit dem betroffenen Key) oder __keyspace@<db>__:<key> (Ereignisse auf einem bestimmten Key).
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.
Keyspace-Benachrichtigungen zu verstehen ist nützliches Wissen für die Reaktion auf Datenänderungen in Redis, eine Fähigkeit, die bestimmte ereignisgesteuerte Muster ermöglicht — obwohl das Verständnis seiner Einschränkungen gleichermaßen wichtig ist.
Diese Funktion ermöglicht es Clients, sich auf Ereignisse über Key-Änderungen (Sets, Löschungen und besonders Abläufe) über Pub/Sub zu abonnieren, sodass Redis die Anwendung benachrichtigen kann, wenn sich Daten ändern.
Das Ablaufereignis insbesondere ermöglicht ein häufiges, elegantes Muster: den TTL eines Keys als Timer/Scheduler zu verwenden — setzen Sie einen Key so, dass er nach einer gewissen Verzögerung abläuft, und die Ablauf-Benachrichtigung löst eine Aktion aus (Freigabe gehaltener Lagerbestände nach einer Haltefrist, Behandlung von Session-Ablauf, Ausführung verzögerter Jobs), was zeitgesteuerte Verhalten ohne ein separates Planungssystem bietet.
Zu verstehen, wie man Benachrichtigungen aktiviert (notify-keyspace-events) und sich auf die speziellen Keyevent/Keyspace-Kanäle abonniert, ist der praktische Mechanismus.
Kritisch ist, die Einschränkungen zu verstehen, um diese richtig zu nutzen: Da sie auf Pub/Sub aufgebaut sind, sind sie "Fire-and-Forget" (Ereignisse ohne verbundenen Subscriber gehen dauerhaft verloren — also unzuverlässig für kritische Ereignisse), das Ablaufereignis hinkt dem exakten TTL hinterher (wird ausgelöst, wenn der Key tatsächlich durch Lazy/Active-Expiration entfernt wird, sodass das Timing nicht präzise ist), und es hat Overhead bei hohem Volumen — was bedeutet, dass für zuverlässige Ereignisbehandlung Streams oder ein anderer Mechanismus besser ist.
Dieses Bewusstsein verhindert eine zu starke Abhängigkeit von Benachrichtigungen für garantierte Zustellung.
Da die Reaktion auf Redis-Datenänderungen (besonders Abläufe als Timer) ein nützliches Muster für verzögerte Aktionen und Planung ist, und da Keyspace-Benachrichtigungen es bieten, aber mit wichtigen Zuverlässigkeits- und Timing-Einschränkungen (Vererbung von Pub/Subs "Fire-and-Forget"-Natur), ist das Verständnis von Keyspace-Benachrichtigungen — was sie sind, das Ablaufereignis-als-Timer-Muster und besonders die Einschränkungen — wertvoll, praktisch relevantes Wissen für die angemessene Verwendung dieser Funktion, während man weiß, wann seine Einschränkungen einen zuverlässigeren Ansatz erfordern.