O que são notificações de keyspace do Redis?

Question

Accepted Answer

**Notificações de keyspace** permitem que clientes se inscrevam (via Pub/Sub) em eventos sobre mudanças em chaves — como uma chave sendo definida, deletada ou **expirada**. Elas possibilitam reagir a mudanças de dados no Redis, sendo o evento de expiração um gatilho particularmente comum e útil. ## Habilitando e se inscrevendo ```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 ``` Você habilita notificações (`notify-keyspace-events`, escolhendo quais eventos) e se inscreve em canais especiais: `__keyevent@__:` (eventos de um tipo, ex. `expired`, com a chave afetada) ou `__keyspace@__:` (eventos em uma chave específica). ## O evento de expiração: um padrão comum ```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 ``` ## Ressalvas importantes ```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. ``` ## Por que isso importa Compreender notificações de keyspace é conhecimento útil para **reagir a mudanças de dados no Redis**, uma capacidade que permite certos padrões orientados a eventos — embora compreender suas limitações seja igualmente importante. O recurso permite que clientes **se inscrevam em eventos sobre mudanças de chaves** (definições, deleções e especialmente **expirações**) via Pub/Sub, possibilitando que o Redis notifique a aplicação quando os dados mudam. O **evento de expiração em particular** alimenta um padrão comum e elegante: usar o TTL de uma chave como um **temporizador/agendador** — defina uma chave para expirar após algum atraso, e a notificação de expiração dispara uma ação (liberando inventário retido após um período de espera, tratando expiração de sessão, executando jobs atrasados), fornecendo comportamento de ação agendada sem um sistema de agendamento separado. Compreender como habilitar notificações (`notify-keyspace-events`) e se inscrever nos canais especiais de keyevent/keyspace é o mecanismo prático. Criticamente, compreender as **ressalvas** é essencial para usar isso corretamente: porque é construído sobre **Pub/Sub, é fire-and-forget** (eventos sem subscriber conectado são permanentemente perdidos — então é não confiável para eventos críticos), o **evento de expiração é atrasado** em relação ao TTL exato (disparando quando a chave é realmente removida por expiração lazy/ativa, então o timing não é preciso), e tem sobrecarga em alto volume — significando que para tratamento de eventos confiável, Streams ou outro mecanismo é melhor. Essa conscientização evita depender demais de notificações para entrega garantida. Como reagir a mudanças de dados do Redis (especialmente expirações como temporizadores) é um padrão útil para ações atrasadas e agendamento, e como notificações de keyspace a proporcionam mas com limitações importantes de confiabilidade e timing (herdando a natureza fire-and-forget do Pub/Sub), compreender notificações de keyspace — o que são, o padrão de expiração-como-temporizador, e especialmente as ressalvas — é conhecimento valioso e praticamente relevante para usar esse recurso apropriadamente enquanto se sabe quando suas limitações requerem uma abordagem mais confiável.