REDIS Key Notification

Commands Clients Documentation Community DOWNLOAD support Licensejoin us in London October 19th for the 2nd Redis develope RS Day and October 20th for the Redis unconference London.redis keyspace Notifications

IMPORTANT Keyspace Notifications is a feature available since 2.8.0

Feature Overview

Keyspace notifications allows clients to subscribe to PUB/SUB channels in order to receive events affecting the Redis data Set in some.

Examples of the events possible to receive is the following:

• All the commands affecting a given key.
• All of the keys receiving an Lpush operation.
• All the keys expiring in the database 0.

Events is delivered using the normal pub/sub layer of Redis, so clients implementing pub/sub is able to use this feature Without modifications.

Because Redis Pub/sub is fire and forget currently there are no-i-use-feature if you application demands Reliable notification of events, that's, if your pub/sub client disconnects, and reconnects later, all the even TS delivered during the time the client was disconnected is lost.

In the future there is plans to allow for more reliable delivering of events, but probably this would be addressed at a mo Re general level either bringing reliability to pub/sub itself, or allowing Lua scripts to intercept pub/sub messages to P Erform operations like pushing the events into a list.

Type of events

Keyspace Notifications is implemented sending, distinct type of events for every operation affecting the Redis data SP Ace. For instance a DEL operation targeting the key named mykey in database would 0 trigger the delivering of both messages, Exactly equivalent to the following, PUBLISH commands:

PUBLISH [email protected]__:mykey delPUBLISH [email protected]__:del mykey

It's easy-to-see-how-one channel allows to listen-all the events targeting the key and the other mykey channel allows To obtain information the "All the Keys" is the target of a del operation.

The first kind of event, with keyspace prefix in the channel was called a key-space notification, while the second, W ith keyevent The prefix, is called a key-event notification.

In the above example a del event is generated for the key mykey . What happens are that:

• The Key-space channel receives as message the name of the event.
• The Key-event channel receives as message the name of the Key.

It is possible to enable only one kind of notification in order to deliver just the subset of events we are interested in.

Configuration

By default Keyspace events notifications is disabled because while not very sensible the feature uses some CPU power. Notifications is enabled using the notify-keyspace-events redis.conf or via the CONFIG SET.

Setting the parameter to the empty string disables notifications. In order to enable the feature a Non-empty string was used, composed of multiple characters, where every character has a SP Ecial meaning according to the following table:

K     Keyspace events, published with [email protected]<db>__ prefix.E     Keyevent events, published with [email protected]<db>__ prefix.g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...$     String commandsl     List commandss     Set commandsh     Hash commandsz     Sorted set commandsx     Expired events (events generated every time a key expires)e     Evicted events (events generated when a key is evicted for maxmemory)A     Alias for g$lshzxe, so that the "AKE" string means all the events.

At least K or E should is present in the string, otherwise no event would be delivered regardless of the rest of th E string.

For instance to enable just Key-space events for lists, the configuration parameter must is set Kl to, and so forth.

The string KEA can is used to enable every possible event.

Events generated by different commands

Different commands generate Different kind of events according to the following list.

• DEL generates a del event for every deleted key.
• RENAME generates, a event for rename_from the source key, and a event for the rename_to destination key.
• EXPIRE generates an expire event if an EXPIRE are set to the key, or a expired event every time setting an EXPIRE results in To the key being deleted (see EXPIRE documentation for more info).
• SORT generates a sortstore event when was STORE used to set a new key. If The resulting list is empty, and the STORE option is used, and there was already a existing key with that name, the RE Sult is and the key is deleted, so a del event was generated in this condition.
• SET and all its variants (Setex, setnx,getset) generate set events. However Setex would also generate an expire events.
• MSET generates a separated set event for every key.
• SETRANGE generates a setrange event.
• INCR, DECR, Incrby, Decrby commands all generate incrby events.
• Incrbyfloat generates an incrbyfloat events.
• APPEND generates an append event.
• Lpush and Lpushx generates a single lpush event, even in the Variadic case.
• Rpush and Rpushx generates a single rpush event, even in the Variadic case.
• Rpop generates an rpop event. Additionally a del event is generated if the key is removed because the last element from the list was popped.
• Lpop generates an lpop event. Additionally a del event is generated if the key is removed because the last element from the list was popped.
• Linsert generates an linsert event.
• LSET generates an lset event.
• LTRIM generates an ltrim event, and additionally a del event if the resulting list was empty and the key is removed.
• Rpoplpush and Brpoplpush generate an event and an rpop lpush event. In both cases the order is guaranteed (the event would always be lpush delivered after the rpop event). Additionally a del event would be generated if the resulting list was zero length and the key is removed.
• Hset, hsetnx and hmset all generate a single hset event.
• Hincrby generates an hincrby event.
• Hincrbyfloat generates an hincrbyfloat event.
• Hdel generates a single hdel event, and an additional del event if the resulting hash was empty and the key is removed.
• Sadd generates a single sadd event, even in the Variadic case.
• Srem generates a single srem event, and an additional del event if the resulting set are empty and the key is removed.
• Smove generates an srem event for the source key, and a sadd event for the destination key.
• SPOP generates an spop event, and a additional del event if the resulting set is empty and the key is removed.
• Sinterstore, Sunionstore, Sdiffstore generate sinterstore , sunionostore sdiffstore events respectively. In the special case the resulting set was empty, and the key where the result is stored already exists, an del event is GE Nerated since the key is removed.
• ZINCRGenerates a zincr event.
• Zadd generates a single zadd event even when multiple elements is added.
• Zrem generates a single zrem event even when multiple elements is deleted. When the resulting sorted set is empty and the key was generated, an additional del event is generated.
• ZREMBYSCOREGenerates a single zrembyscore event. When the resulting sorted set is empty and the key was generated, an additional del event is generated.
• ZREMBYRANKGenerates a single zrembyrank event. When the resulting sorted set is empty and the key was generated, an additional del event is generated.
• Zinterstore and Zunionstore respectively generate zinterstore and zunionstore events. In the special case the resulting sorted set is empty, and the key where the result is stored already exists, a del even T is generated since, the key is removed.
• Every time a key with a time to live associated was removed from the data set because it expired, an expired event is Generat Ed.
• Every time a key is evicted from the data set in order to free memory as a result maxmemory of the policy, an evicted event is G Enerated.

IMPORTANT All the commands generate events only if the target key is really modified. For instance an srem deleting a non-existing element from a Set won't actually change the value of the key, so no event would be generated.

If in doubt about what events are generated for a given command, the simplest thing to does is to watch yourself:

$ redis-cli config set notify-keyspace-events KEA$ redis-cli --csv psubscribe ‘__key*__:*‘Reading messages... (press Ctrl-C to quit)"psubscribe","__key*__:*",1

At the the the redis-cli another terminal to send commands to the Redis server and watch the events generated:

"pmessage","__key*__:*","[email protected]__:foo","set""pmessage","__key*__:*","[email protected]__:set","foo"...

Timing of expired Events

Keys with a time to live associated is expired by Redis in ways:

• When the key was accessed by a command and was found to be expired.
• Via a background system, looks for expired keys in background, incrementally, and order to being able to also collect keys That is never accessed.

expiredThe events was generated when a key was accessed and is found to being expired by one of the above systems, as a result There is no guarantees that the Redis server would be able to generate the event at the time of the key time to expired live re Aches the value of zero.

If No command targets the key constantly, and there is many keys with a TTL associated, there can be a significant delay Between the time the key time to live drops to zero, and the time of the expired event is generated.

Basically expired events is generated when the Redis server deletes the key and is the time to live Theoreti Cally reaches the value of zero.

This website is open source software. See all credits.

Sponsored by

REDIS Key Notification