Keyspace Notifications

Events about your keys

Redis can publish Pub/Sub events when keys change, called keyspace notifications. They are disabled by default because they cost CPU; enable them with the notify-keyspace-events setting, choosing classes of events: for example E (keyevent channels) plus x (expired events) gives Ex. Events are published on two channel families: keyspace channels (__keyspace@0__:mykey, message is the event name such as set or del) and keyevent channels (__keyevent@0__:expired, message is the key name). A common use is reacting to expirations, such as ending a reservation hold. Two important caveats: they are ordinary Pub/Sub, so they are lost if no client is connected; and an expired event is generated when Redis actually deletes the key, either when it is accessed or when the background expiry cycle finds it, which can be some time after the TTL ran out. In a cluster, each node emits events only for its own keys, so subscribers must listen on every node.

Reacting to expired keys

Enable expiration events, then subscribe to the keyevent channel.

redis-cli CONFIG SET notify-keyspace-events Ex

# subscriber: receives the names of keys as they expire in database 0
redis-cli PSUBSCRIBE '__keyevent@0__:expired'

# elsewhere: a 10-minute seat hold
redis-cli SET hold:seat:12A user:42 EX 600
# about 10 minutes later the subscriber receives "hold:seat:12A"
# (possibly a little later, when Redis actually evicts the expired key)

Do not build critical timers on expiry events

Because expiry events can be delayed or lost, use them as a hint, not the source of truth. For reliable delayed jobs, store due times in a sorted set or database and poll, or use a scheduler.

त्वरित जाँच: Why might an expired-key notification arrive later than the key's TTL?

• Redis batches notifications hourly
• Notifications are stored on disk first
• Expired keys are never notified
• The event fires when Redis actually removes the key, which can happen after the TTL elapses