Redis官方文档(12) ——键空间通知

Redis3官方文档(12)
——键空间通知

重要：键空间通知(Keyspace notifications)是从2.8.0开始可用的特性。

    特性概述(Feature overview)
    键空间通知允许客户端订阅Pub/Sub频道来接收以某种方式影响Redis数据集的事件。
    可能受到的样例事件如下：

• 影响指定键的所有命令。
• 接收LPUSH操作的所有键。
• 数据库0中过期的所有键。

    事件通过普通的Redis的发布/订阅层传递，所以实现了发布/订阅的客户端不用修改就可以使用这个特性。
    因为Redis的发布/订阅当前是发送即忘(fire and forget)的，所以如果你的应用需要可靠的事件通知则不适合这个特性，也就是说，如果你的发布/订阅客户端断开了连接，然后重新连接上，所有在客户端断开期间传递的消息都将丢失。
    未来有计划允许更加可靠的事件传递，但是这很可能在一个更通用的层来处理，让发布/订阅本身更稳定，或者允许Lua脚本来拦截发布/订阅消息来执行像压入事件到列表中这样的操作。

    事件类型(Type of events)
    键空间通知被实现为位每个影响Redis数据空间的操作发送两种不同类型的事件。例如，针对数据库0中的名为mykey的键的DEL操作会触发传递两条消息，完全等价于下面两个PUBLISH命令：

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

    很容易看到如何使一个频道允许监听针对键mykey的所有事件，使另一个频道允许获得关于针对DEL操作的所有键的信息。
    第一种类型的事件，频道名有keyspace前缀，被称为键空间通知(Key-space notification)，第二种类型，前缀为keyevent，被称为键事件通知(Key-event notification)。
    在上面的例子中，mykey键产生了一个del事件。发生了什么：

• 键空间频道收到了事件名称的消息。
• 键事件频道收到了键名称的消息。

    可以只开启一种类型的通知，来传递只是我们感兴趣的事件的子集。

    配置(Configuration)
    键空间事件通知默认被禁用，因为这个特性消耗CPU电量不是很明智。使用redis.conf的otify-keyspace-events，或者通过CONFIG SET来开启通知。
    设置参数为空字符串将禁用通知。为了开启这个特性，需要使用一个由多个字符组成的非空字符串， 按照下面的表格，每一个字符都有其特殊的含义：

K     Keyspace events, published with __keyspace@<db>__ prefix.
E     Keyevent events, published with __keyevent@<db>__ prefix.
g     Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
$     String commands
l     List commands
s     Set commands
h     Hash commands
z     Sorted set commands
x     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.

    字符串中至少要出现K或者E，否则无论字符串的其他部分是什么都不会传递任何事件。
例如，只为列表开启键空间事件，配置参数必须设置为Kl，等等。
    字符串KEA可以用于开启每一个可能事件。

    不同命令产生的事件(Events generated by different commands)
    按照下面的清单，不同的命令产生不同类型的事件。

• DEL 为每一个被删除的键产生一个del事件。
• RENAME 产生两个事件，为源键产生一个rename_from事件，为目标键产生一个rename_to事件。
• EXPIRE 当为键设置过期时产生一个expire事件，或者每当设置了过期的键被删除时产生一个expired事件(查看EXPIRE文档获取更多信息)。
• SORT 当STORE用于设置一个新键时产生一个sortstore事件。当结果列表为空，并且使用了STORE选项，并且已经有一个该名字的键存在，那么这个件键被删除，所以这种条件下或产生一个del事件。
• SET及其所有变种(SETEX, SETNX,GETSET) 产生set事件。但是SETEX还会产生一个expire事件。
• MSET 为每个键产生一个单独的set事件。
• SETRANGE 产生一个setrange事件。
• INCR, DECR, INCRBY, DECRBY 都产生incrby事件。
• INCRBYFLOAT 产生一个incrbyfloat事件。
• APPEND 产生一个append事件。
• LPUSH和LPUSHX 产生单个lpush事件，即使在可变情况下(even in the variadic case)。
• RPUSH和RPUSHX 产生单个rpush事件，即使在可变情况下(even in the variadic case)。
• RPOP 产生一个rpop事件。如果键由于最后一个元素被从列表中弹出而导致删除，会又产生一个del事件。
• LPOP 产生一个lpop事件。如果键由于最后一个元素被从列表中弹出而导致删除，会又产生一个del事件。
• LINSERT 产生一个linsert事件。
• LSET 产生一个lset事件。
• LREM 产生一个lrem事件。如果结果列表为空并且键被删除，会又产生一个del事件。
• LTRIM 产生一个ltrim事件。如果结果列表为空并且键被删除，会又产生一个del事件。
• RPOPLPUSH和BRPOPLPUSH 产生一个rpop事件和一个lpush事件。两种情况下顺序都能保证 (lpush事件总是在rpop事件之后被传递) 如果结果列表长度为零并且键被删除，会又产生一个del事件。
• HSET, HSETNX和HMSET 都产生单个hset事件。
• HINCRBY 产生一个hincrby事件。
• HINCRBYFLOAT 产生一个hincrbyfloat事件。
• HDEL 产生单个hdel事件。如果结果哈希为空并且键被删除，会又产生一个del事件。
• SADD 产生单个sadd事件，即使在可变情况下(even in the variadic case)。
• SREM 产生单个srem事件。如果结果集合为空并且键被删除，会又产生一个del事件。
• SMOVE 为源键产生一个srem事件为目标键产生一个sadd事件。
• SPOP 产生一个spop事件。如果结果集合为空并且键被删除，会又产生一个del事件。
• SINTERSTORE, SUNIONSTORE, SDIFFSTORE 分别产生sinterstore，sunionostore，sdiffstore事件。在特殊情况下，集合为空，且存储结果的键已经存在，由于键被删除，会产生一个del事件。
• ZINCR 产生一个zincr事件。
• ZADD产生单个zadd事件，即使添加了多个元素。.
• ZREM 产生单个zrem事件，即使删除了多个元素。当结果有序集合为空，并且键被生成时，会产生一个额外的del事件。
• ZREMBYSCORE 产生单个zrembyscore事件。当结果有序集合为空，并且键被生成时，会产生一个额外的del事件。
• ZREMBYRANK 产生单个zrembyrank事件。当结果有序集合为空，并且键被生成时，会产生一个额外的del事件。
• ZINTERSTORE和ZUNIONSTORE 分别产生zinterstore和zunionstore事件。在特殊情况下，集合为空，且存储结果的键已经存在，由于键被删除，会产生一个del事件。
• 每当一个关联有生存事件的键由于过期而被从数据集中删除时会产生一个expired事件。
• 每当一个键由于maxmemory策略而从数据集中被淘汰以节省内存时会产生一个evicted事件。

    重要：所有的命令只有当目标键被真正修改时才会产生事件。例如，SREM从一个集合中删除一个不存在的元素不会真正改变键的值，所以没有事件产生。
    如果怀疑一个给定的命令的事件是如何产生的，最简单的事情就是观察你自己：

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

    此时，在另一个终端中使用redis-cli来发送命令给Redis服务器，来观察产生的时间：

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

    expired事件的计时(Timing of expired events)
    Redis有两种方式使关联有生存事件的键过期：

• 当键被命令访问并且发现已经过期时。
• 通过一个后台系统在后台增量地寻找已过期键，这样可以收集到从来不被访问的键。

    当键通过上面任何一个系统而被访问且发现已经过期时，产生expired事件，因而不能保证Redis服务器刚好在键的生存时间到达值0时产生expired事件。
    如果没有命令持续访问键，并且有许多关联TTL的键，键的生存时间降低为零的时间和expried事件产生的时间会有很大的延迟。
    基本上，当Redis服务器删除键时才产生expried事件，而不是理论上生存时间到达0值。
===============================================================================
    大家好，我是阮威。华中科技大学，计算机软件专业硕士。毕业后加入腾讯，先后在腾讯电子商务部和无线游戏产品部工作，现供职于欢聚时代基础产品部。IT男，至今。欢迎大家收听我的公众账号。

评论

1 楼 WeaponLin 2017-04-01  

已过期的键不是在内存中被删除了吗？  还能找到吗？