Что такое уведомления о пространстве ключей (keyspace notifications) в Redis?

Question

Accepted Answer

**Уведомления о пространстве ключей** позволяют клиентам подписываться (через Pub/Sub) на события об изменениях ключей — такие как установка, удаление или **истечение** ключа. Они позволяют реагировать на изменения данных в Redis, при этом событие истечения является особенно распространённым и полезным триггером. ## Включение и подписка ```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 ``` Вы включаете уведомления (`notify-keyspace-events`, выбирая, какие события отслеживать) и подписываетесь на специальные каналы: `__keyevent@__:` (события определённого типа, например `expired`, с затронутым ключом) или `__keyspace@__:` (события, касающиеся конкретного ключа). ## Событие истечения: распространённый паттерн ```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 ``` ## Важные ограничения ```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. ``` ## Почему это важно Понимание уведомлений о пространстве ключей — полезное знание для **реакции на изменения данных в Redis**, возможности, которая позволяет реализовать определённые паттерны, управляемые событиями — хотя понимание его ограничений не менее важно. Эта функция позволяет клиентам **подписываться на события об изменениях ключей** (установке, удалении и особенно **истечении**) через Pub/Sub, позволяя Redis уведомлять приложение об изменении данных. **Событие истечения в частности** обеспечивает распространённый и элегантный паттерн: использование TTL ключа как **таймера/планировщика** — установите ключ на истечение через некоторую задержку, и уведомление об истечении запустит действие (освобождение зарезервированного инвентаря после периода ожидания, обработка истечения сессии, запуск отложенных задач), обеспечивая поведение запланированного действия без отдельной системы планирования. Понимание того, как включить уведомления (`notify-keyspace-events`) и подписаться на специальные каналы keyevent/keyspace, является практическим механизмом. Критически важно понимание **ограничений**: поскольку это построено на основе **Pub/Sub, это «отправить и забыть»** (события без подключённого подписчика безвозвратно теряются — поэтому это ненадёжно для критических событий), **событие истечения отстаёт** от точного TTL (срабатывает при фактическом удалении ключа через ленивое или активное истечение, поэтому синхронизация неточна), и это имеет накладные расходы при высокой нагрузке — что означает, что для надёжной обработки событий лучше использовать Streams или другой механизм. Это понимание предотвращает чрезмерную полаганию на уведомления для гарантированной доставки. Поскольку реакция на изменения данных Redis (особенно истечения как таймеры) — полезный паттерн для отложенных действий и планирования, и поскольку уведомления о пространстве ключей это обеспечивают, но с важными ограничениями по надёжности и синхронизации (наследуя природу Pub/Sub «отправить и забыть»), понимание уведомлений о пространстве ключей — что они такое, паттерн истечения-как-таймер и особенно ограничения — является ценным, практически релевантным знанием для надлежащего использования этой функции, при этом зная, когда её ограничения требуют более надёжного подхода.