Czym są powiadomienia keyspace w Redis?

Question

Accepted Answer

**Powiadomienia keyspace** umożliwiają klientom subskrybowanie (za pośrednictwem Pub/Sub) zdarzeń dotyczących zmian kluczy — takich jak ustawienie klucza, usunięcie lub **wygaśnięcie**. Umożliwiają reagowanie na zmiany danych w Redis, gdzie zdarzenie wygaśnięcia jest szczególnie powszechnym i użytecznym wyzwalaczem. ## Włączanie i subskrybowanie ```bash # keyspace notifications are OFF by default — enable the event classes you want CONFIG SET notify-keyspace-events KEA # K=keyspace, E=keyevent, A=all event types # subscribe to events: e.g. all expirations across the database PSUBSCRIBE "__keyevent@0__:expired" # fires when ANY key expires (with the key name) PSUBSCRIBE "__keyspace@0__:mykey" # all events on a specific key ``` Włączasz powiadomienia (`notify-keyspace-events`, wybierając, które zdarzenia) i subskrybujesz specjalne kanały: `__keyevent@__:` (zdarzenia danego typu, np. `expired`, wraz z dotkniętym kluczem) lub `__keyspace@__:` (zdarzenia dotyczące konkretnego klucza). ## Zdarzenie wygaśnięcia: powszechny wzorzec ```text 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 ``` ## Ważne zastrzeżenia ```text ⚠️ 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. ``` ## Dlaczego to ważne Zrozumienie powiadomień keyspace jest użyteczną wiedzą do **reagowania na zmiany danych w Redis**, możliwości, która umożliwia pewne wzorce oparte na zdarzeniach — choć zrozumienie jej ograniczeń jest równie ważne. Funkcja umożliwia klientom **subskrybowanie zdarzeń dotyczących zmian kluczy** (ustawienia, usunięcia, a zwłaszcza **wygaśnięcia**) za pośrednictwem Pub/Sub, co umożliwia Redis powiadomienie aplikacji o zmianach danych. **Zdarzenie wygaśnięcia w szczególności** napędza powszechny, elegancki wzorzec: użycie TTL klucza jako **timera/harmonogramu** — ustaw klucz do wygaśnięcia po pewnej opóźnieniu, a powiadomienie o wygaśnięciu wyzwala akcję (zwolnienie wstrzymanego inwentarza po okresie wstrzymania, obsługa wygaśnięcia sesji, uruchamianie opóźnionych zadań), zapewniające zachowanie zaplanowanych akcji bez oddzielnego systemu harmonogramowania. Zrozumienie, jak włączyć powiadomienia (`notify-keyspace-events`) i subskrybować specjalne kanały keyevent/keyspace, to praktyczny mechanizm. Krytycznie ważne jest zrozumienie **zastrzeżeń**: ponieważ jest zbudowany na bazie **Pub/Sub, jest fire-and-forget** (zdarzenia bez podłączonego subskrybenta są na zawsze tracone — więc jest to zawodne dla krytycznych zdarzeń), **zdarzenie wygaśnięcia opóźnia się** w stosunku do dokładnego TTL (jest wywoływane, gdy klucz jest faktycznie usunięty przez leniwe/aktywne wygaśnięcie, więc czas nie jest precyzyjny) i ma narzut na dużych wolumenach — co oznacza, że dla niezawodnej obsługi zdarzeń, Streams lub inny mechanizm jest lepszy. Ta świadomość zapobiega przedmiotowemu poleganiu na powiadomieniach w celu gwarantowanej dostawy. Ponieważ reagowanie na zmiany danych Redis (zwłaszcza wygaśnięcia jako timery) jest użytecznym wzorcem dla opóźnionych akcji i harmonogramowania, a powiadomienia keyspace je zapewniają, ale z istotnymi ograniczeniami niezawodności i czasu (dziedzicząc fire-and-forget charakter Pub/Sub), zrozumienie powiadomień keyspace — czym są, wzorzec wygaśnięcia-jako-timera, a zwłaszcza zastrzeżenia — to cenna, praktycznie istotna wiedza do właściwego używania tej funkcji przy jednoczesnym wiedzy, kiedy jej ograniczenia wymagają bardziej niezawodnego podejścia.