Key space Notification (KEYSPACE notification) _ Key space

Redis key Space Notification (KEYSPACE notification)

This document is translated from: Http://redis.io/topics/notifications.

The key space notification feature is still under development, and the content described in this document, as well as the specific implementation of the functionality, may change over the next few weeks, please be informed. Features Overview

A key space notification allows a client to subscribe to a channel or mode to receive events that have altered the Redis dataset in some way.

The following are examples of events sent by key space notifications: all the commands that modify the keys. All keys that receive the Lpush command. All expired keys in the No. 0 database.

Events are distributed through the Redis subscription and publishing feature (Pub/sub), so all clients that support subscription and publishing can use the key space notification function directly without making any changes.

Because the current subscription and publishing feature of Redis is to send a fire and forget policy, if your program requires reliable event notification (reliable notification of events), the current key space notification may not be right for you: When the client that subscribes to the event is disconnected, it loses all events that were distributed to it during the disconnection.

More reliable event distribution will be supported in the future, which can be implemented by making subscriptions and publishing more reliable itself, or by listening to the subscription and publication of messages (message) in Lua scripts, thus enabling actions like pushing events to a list. Type of Event

For each operation that modifies the database, the key space notification sends two different types of events.

For example, when you execute the DEL command on the key MyKey of database No. 0, the system will distribute two messages, equivalent to the following two PUBLISH commands:

PUBLISH __keyspace@0__:mykey del
PUBLISH __keyevent@0__:del MyKey

Subscribe to the first channel __keyspace@0__:mykey can receive all events in the No. 0 database that modify key MyKey, while subscribing to the second channel __keyevent@0__:del can receive all keys that perform del commands in the NO. 0 database.

A channel prefixed by Keyspace is called a key space notification (KEY-SPACE notification), and a channel prefixed by KeyEvent is called a key event notification (key-event notification).

When del MyKey command executes: The subscriber of the key space channel will receive the name of the event being executed, in this case, Del. The subscriber of the key event channel will receive the name of the key of the event being executed, in this case, the MyKey. Configuration

Because the key space notification function needs to consume some CPU, the feature is turned off under the default configuration.

You can turn on or off the key space notification feature by modifying the redis.conf file, or by using the CONFIG SET command directly: When the notify-keyspace-events option argument is an empty string, the feature is turned off. On the other hand, when the argument is not an empty string, the feature is turned on.

The notify-keyspace-events parameter can be any combination of the following characters, which specifies the type of notification the server should send: the notification of the character sent by the K-key space notification, all notifications with __keyspace@<db>__ as the prefix E-key event notification, All notifications are based on the notification of a generic command that has a __keyevent@<db>__ prefix g DEL, EXPIRE, RENAME, and so on. $ string Command notification L List command notifications of Notifications H hash command notifications Z ordered set of commands Notification x Expiration event: Sends an e expulsion (evict) event whenever an expired key is deleted: sends a parameter G$LSHZXE alias whenever a key is deleted because of maxmemory policy

There must be at least one K or E in the input parameter, otherwise no notification will be distributed regardless of the rest of the parameters.

For example, if you just want to subscribe to a list-related notification in the key space, the argument should be set to Kl, and so forth.

Setting the argument to the string "Ake" indicates that all types of notifications are sent. Notifications generated by commands

The following list records the different notifications produced by different commands: The del  command generates a  del  notification for each deleted key. rename  generates two notifications: generates a  rename_from  notification for the source key, and generates a  rename_to  for the target key (destination key) Notice. expire  and  EXPIREAT  produces a  expire  notification when the key is properly set to expire. When the  EXPIREAT  set time has expired, or when the  EXPIRE  incoming time is a negative value, the key is deleted and a  del  notification is generated. sort  produces a  sortstore  event when the command has a  STORE  parameter. If the key that the  STORE  indicates to hold the sort result already exists, the program also sends a  del  event. set  and all of its variants (setex ,  SETNX , and  getset) produce  set  notifications. Where  SETEX  will also produce  expire  notifications. mset  generates a  set  notification for each key. setrange  produces a  setrange  notice. incr ,  DECR ,  INCRBY  and  DECRBY  all produce  incrby  notifications. incrbyfloat  Production  incrbyfloat  notification. append  Production  append  notification. Both lpush  and  LPUSHX  produce a single  lpush  notification, even when there are multiple input elements. Both rpush  and  RPUSHX  produce a single  rpush  notification, even when there are multiple input elements. rpop  Production  rpop  notification. If the element being ejected is the last element of the list, a  del  notification will also be generated. lpop  Production  lpop  notification. If the element being ejected is the last element of the list, a  del  notification will also be generated. linsert  produces a  linsert  notice. lset  produces a  lset  notice. ltrim  produces a  ltrim  notice. If the list key is emptied after the  LTRIM  is executed, a  del  notification is also generated. rpoplpush  and  BRPOPLPUSH  produces a  rpop  notification, as well as a  lpush  notification. Two commands will ensure that  rpop  notifications are distributed prior to  lpush  notification. If you eject the element from the key, the pop-up list key is emptied, and a  del  notification is generated. hset ,  HSETNX  and  HMSET  all produce only one  hset  notification. hincrby  produces a  hincrby  notice. hincrbyfloat  produces a  hincrbyfloat  notice. hdel  produces a  hdel  notice. If the hashing is emptied after the execution of  HDEL , a  del  notification is also generated. sadd  produces a  sadd  notification, even when there are multiple input elements. srem  generates a  srem  notification, and if the collection key is emptied after  SREM , a  del  notification is generated. smove  generates a  srem  notification for the source key, and generates a  sadd  event for the target key (destination key). spop  generationA  spop  event. If the collection key is emptied after the  SPOP  is executed, a  del  notification is also generated. sinterstore ,  SUNIONSTORE  and  SDIFFSTORE  respectively produce  sinterstore ,  sunionostore   and  sdiffstore  three notifications. If the key used to save the result already exists, a  del  notification will also be generated. zincrby  produces a  zincr  notice. Please note that you are not symmetrical. zadd  produces a  zadd  notification, even when there are multiple input elements. zrem  produces a  zrem  notification, even when there are multiple input elements. If the ordered collection key is emptied after  ZREM  is executed, a  del  notification is also generated. zremrangebyscore  produces a  zrembyscore  notice. Please note that you are not symmetrical. If the key used to save the result already exists, a  del  notification is also generated. zremrangebyrank  produces a  zrembyrank  notice. Please note that you are not symmetrical. If the key used to save the result already exists, a  del  notification is also generated. zinterstore  and  ZUNIONSTORE  respectively produce  zinterstore  and  zunionstore  two kinds of notifications. If the key used to save the result already exists, a  del  notification will also be generated. A  expired  notification occurs whenever a key is deleted because it is expired. A  evicted  notification occurs whenever a key is deleted to reclaim memory because of a  maxmemory  policy.

All commands are only notified when the key is changed.

For example, when Srem tries to delete an element that does not exist in the collection, the deletion fails because there is no real change key, so the action does not send a notification.

If you have questions about the notifications that are generated by the command, it is best to use the following command to verify yourself:

$ redis-cli config set notify-keyspace-events KEA
$ redis-cli--csv psubscribe ' __key*__:* ' Reading
messages ... (Press Ctrl-c to quit)
" Psubscribe "," __key*__:* ", 1

Then, as long as you send commands to the Redis client in the other terminals, you can see the notifications that are generated:

"Pmessage", "__key*__:*", "__keyspace@0__:foo", "Set"
"Pmessage", "__key*__:*", "__keyevent@0__:set", "foo"
...

Time to send expired notifications

Redis uses the following two ways to remove expired keys: When a key is accessed, the program checks the key, and if the key has expired, the key is deleted. The underlying system incrementally finds and deletes expired keys in the background to handle keys that have expired but will not be accessed.

Redis produces a expired notification when the expiration key is found by any of the above two programs and the key is deleted from the database.

Redis does not guarantee that the key to the live time (TTL) change to 0 is immediately removed: If the program does not have access to this expiration key, or if there are many keys to the lifetime, then the lifetime of the key changes to 0, until the key is actually deleted, there may be a more significant time interval.

Therefore, the time that Redis produces expired notifications is when the expiration key is deleted, not when the key's lifetime changes to 0.

From:http://redisdoc.com/topic/notification.html