Redis实现之数据库（三）-数据库

过期键删除策略在Redis实现之数据库（二）一小节中，我们知道了数据库键的过期时间都保存在过期字典中，又知道了如果根据过期时间去判断一个键是否过期，现在剩下的问题是：如果一个键过期了，那么它什么时候会被删...

过期键删除策略

在Redis实现之数据库（二）一小节中，我们知道了数据库键的过期时间都保存在过期字典中，又知道了如果根据过期时间去判断一个键是否过期，现在剩下的问题是：如果一个键过期了，那么它什么时候会被删除呢？这个问题有三种可能的答案，它们分别代表了三种不同的删除策略：

定时删除：在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作
惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期。如果过期的话，就删除该键；如果没有过期，就返回该键
定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定

在这三种策略中，第一种和第三种为主动删除，而第二种则为被动删除

定时删除

定时删除策略对内存是最友好的，通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存。另一方面，定期删除策略的缺点是，它对CPU时间是不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响

例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将CPU时间用在处理客户端的命令请求上面，而不是用在删除过期键上面。除此之外，创建一个定时器需要用到Redis服务器中的时间事件，而当前时间事件的实现方式——无序链表，查找一个事件的时间复杂度为O(N)——并不能高效地处理大量时间事件。因此，要让服务器创建大量的定时器，从而实现定时器删除策略，现阶段来说并不现实

惰性删除

惰性删除策略对CPU时间来说是最友好的：程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何CPU时间。惰性删除策略的缺点是，它对内存是不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放

在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远不会被删除（除非用户手动执行FLUSHDB），我们甚至可以将这种情况看作一种内存泄露——无用的垃圾数据占用了大量内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖内存的Redis服务器来说，肯定不是一个好消息

定期删除

从上面对定时删除和惰性删除的讨论来看，这两种删除方式在单一使用时都有明显的缺陷：

定期删除占用太多CPU时间，影响服务器响应时间和吞吐量
惰性删除浪费太多内存，有内存泄露的危险

定期删除策略是两种策略的一种整合和折中：

定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响
除此之外，通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费

定期删除策略的难点是确定删除操作执行的时长和效率：

如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多地消耗在删除过期键上面
如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况

因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行效率

Redis的过期键删除策略

在前一节，我们讨论了定时删除、惰性删除和定期删除三种过期键删除策略，Redis服务器实际使用的是惰性删除和定期删除两种策略，通过配合使用这两种策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。因为前一节已经介绍过惰性删除和定期删除两种策略的概念了，在接下来的两个小节中，我们将对Redis服务器中惰性删除和定期删除的实现进行说明

惰性删除策略的实现

过期键的惰性删除策略由db.c/expireIfNeeded函数实现，所有读写数据库的Redis命令在执行之前都会调用expireIfNeeded函数对输入键进行检查：

如果输入键已经过期，那么expireIfNeeded函数将输入键从数据库中删除
如果输入键未过期，那么expireIfNeeded函数不做任何动作

命令调用expireIfNeeded函数的过程如图1-15所示

图1-15 命令调用expireIfNeeded来删除过期键

expireIfNeeded函数就像一个过滤器，它可以在命令真正执行之前，过滤掉过期的输入键，从而避免命令接触到过期键。另外，因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除，所以每个命令的实现函数都必须能同时处理键存在以及键不存在这两种情况：

当键存在，命令按照键存在的情况执行
当键不存在或者键因为过期而被expireIfNeeded函数删除时，命令按照键不存在的情况进行

举个栗子，图1-16展示了GET命令的执行过程，在这个过程中，命令需要判断键是否存在以及键是否过期，然后根据判断执行合适的操作

图1-16 GET命令的执行过程

定期删除策略的实现

过期键的定期删除策略由redis.c/activeExpireCycle函数实现，每当Redis的服务器周期性操作redis.c/serverCron函数执行时，activeExpireCycle函数就会被调用，它在规定的时间内，分多次遍历服务器中的各个数据库，从数据库的expires字典中随机检查一部分键的过期时间，并删除其中的过期键

整个过程可以用伪代码描述如下：

#默认每次检查的数据库数量
DEFAULT_DB_NUMBERS = 16  
#默认每个数据库检查的键数量  
DEFAULT_KEY_NUMBERS = 20   
#全局变量，记录检查进度
current_db = 0             

def activeExpireCycle():
	#初始化要检查的数据库数量
	#如果服务器的数据库数量比DEFAULT_DB_NUMBERS要小
	#那么以服务器的数据库数量为标准
    if server.dbnum < DEFAULT_DB_NUMBERS：
        db_numbers = server.dbnum
    else:
        db_numbers = DEFAULT_DB_NUMBERS
	#遍历各个数据库
    for i in range(db_numbers):
        #如果current_db的值等于服务器的数据库数量
		#这表示检查程序已经遍历了服务器的所有数据库一次
		#将current_db重置为0，开始新的一轮遍历
        if current_db == server.dbnum:
            current_db = 0
		#获取当前要处理的数据库
        redisDb = sever.db[current_db]
		#将数据库索引加1，指向下一个要处理的数据库
        current_db++
		#检查数据库键
        for j in range(DEFAULT_KEY_NUMBERS):
			#如果数据库中没有一个键带有过期时间，那么跳过这个数据库
            if redisDb.expires.size() == 0: break
			#随机获取一个带有过期时间的键
            key_with_ttl = redisDb.expires.get_random_key()
			#检查键是否过期，如果过期就删除它
            if is_expired(key_with_ttl):
                delete_key(key_with_ttl)
			#已达到时间上线，停止处理
            if reach_time_limit(): return

activeExpireCycle函数的工作模式可以总结如下：

函数每次运行时，都从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键
全局变量current_db会记录当前activeExpireCycle函数检查的进度，并在下一次activeExpireCycle函数调用时，接着上一次的进度进行处理。比如说，如果当前activeExpireCycle函数在遍历10号数据库时返回了，那么下次activeExpireCycle函数执行时，将从11号数据库开始查找并删除过期键
随着activeExpireCycle函数的不断执行，服务器中的所有数据库都会被检查一遍，这时函数将current_db变量重置为0，然后再次开始新一轮的检查工作

AOF、RDB和复制功能对过期键的处理

这一节，我们来看看RDB持久化功能、AOF持久化功能以及复制功能是如何处理数据库的过期键

生成RDB文件

在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB文件中。举个栗子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当执行SAVE命令或者BGSAVE命令时，程序只会将k1和k3的数据保存到RDB文件中，而k2则会被忽略。因此，数据库中包含过期键不会对生成新的RDB文件造成影响

载入RDB文件

在启动Redis服务器时，如果服务器开启了RDB功能，那么服务器将对RDB文件进行载入：

如果服务器以主服务器模式运行，那么在载入RDB文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入RDB文件的主服务器不会造成影响
如果服务器以从服务器模式运行，那么在载入RDB文件时，文件中保存的所有键，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入RDB文件的从服务器也不会造成影响

举个栗子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当服务器启动时：

如果服务器以主服务器模式运行，那么程序只会将k1、k3载入到数据库，k2会被忽略
如果服务器以从服务器模式运行，那么k1、k2、k3都会被载入到数据库

AOF文件写入

当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或定期删除，那么AOF文件不会因为这个过期键而产生任何影响。当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加（append）一条DEL命令，来显示地记录该键已被删除。举个栗子，如果客户端使用GET message命令，试图访问过期的message键，那么服务器将执行以下三个动作：

从数据库中删除message键
追加一条DEL message命令到AOF文件
向执行GET命令的客户端返回空回复

AOF重写

和生成RDB文件类似，在执行AOF重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的AOF文件中。举个栗子，如果数据库包含三个键k1、k2、k3，并且k2已经过期，那么在进行重写工作时，程序只会对k1、k3进行重写，而k2则会被忽略。因此，数据库中包含过期键不会对AOF重写造成影响

复制

当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制：

主服务器在删除一个过期键之后，会显示地向所有服务器发送一个DEL命令，告知从服务器删除这个过期键
从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像未过期键一样来处理过期键
从服务器只有在接收到主服务器发来的DEL命令之后，才会删除过期键

通过由主服务器来控制从服务器统一地删除过期键，可以保证主从服务器数据的一致性，也正是因为这个原因，当一个过期键仍然存在于主服务器的数据库时，这个过期键在从服务器的复制品也会继续存在。举个栗子，有一对主从服务器，它们的数据库中都保存着同样的三个键message、xxx和yyy，其中message为过期键，如图1-17所示

图1-17 主从服务器删除过期键（1）

如果这时有客户端向从服务器发送命令GET message，那么从服务器将发现message键已过期，但从服务器不会删除message键，而是继续将message键的值返回给客户端，就好像message键没有过期一样，如图1-18所示

图1-18 主从服务器删除过期键（2）

假设在此之后，有客户端向主从服务器发送命令GET message，那么服务器发现键message已经过期，主服务器会删除message键，向客户端返回空回复，并向主从服务器发送DEL message命令，如图1-19所示

图1-19 主从服务器删除过期键（3）

从服务器在接收到主服务器发来的DEL message命令之后，也会从数据库中删除message键，在这之后，主从服务器不再保存过期键message了，如图1-20所示

图1-20 主从服务器删除过期键（4）

数据库通知

数据库通知是Redis2.8版本新增加的功能，这个功能可以让客户端通过订阅给定的频道或者模式，来获知数据库中键的变化，以及数据库中命令的执行情况。举个栗子，以下代码展示了客户端如何获取0号数据库中针对message键执行的所有命令：

客户端A订阅message消息

127.0.0.1:6379> config set notify-keyspace-events KEA
OK
127.0.0.1:6379> SUBSCRIBE __keyspace@0__:message
Reading messages... (press Ctrl-C to quit)
1) "subscribe"   					//订阅消息 
2) "__keyspace@0__:message"
3) (integer) 1
1) "message"						//执行SET命令
2) "__keyspace@0__:message"
3) "set"
1) "message"						//执行EXPIRE命令
2) "__keyspace@0__:message"
3) "expire"
1) "message"						//执行DEL命令
2) "__keyspace@0__:message"
3) "del"

客户端B修改message

127.0.0.1:6379> SET message "hello world"
OK
127.0.0.1:6379> EXPIRE message 300
(integer) 1
127.0.0.1:6379> DEL message
(integer) 1

根据发回的通知显示，先后共有SET、EXPIRE、DEL三个命令对message进行了操作，对比客户端B，确实是这样。这一类关注“某个键执行了什么命令”的通知称为键空间通知，除此之外，还有另一类称为事件通知，它们关注的是“某个命令被什么键执行了”

以下就是一个键事件通知的例子，代码展示了客户端如何获取0号数据库的所有执行DEL命令的键

客户端订阅了DEL事件

127.0.0.1:6379> config set notify-keyspace-events KEA
OK
127.0.0.1:6379> SUBSCRIBE __keyevent@0__:del
Reading messages... (press Ctrl-C to quit)
1) "subscribe"					//订阅消息
2) "__keyevent@0__:del"
3) (integer) 1
1) "message"					//键message执行了DE命令
2) "__keyevent@0__:del"
3) "message"
1) "message"					//键numbers执行了DE命令
2) "__keyevent@0__:del"
3) "numbers"
1) "message"					//键key执行了DE命令
2) "__keyevent@0__:del"
3) "key"

客户端B所做的操作

127.0.0.1:6379> SET message "hello world"
OK
127.0.0.1:6379> DEL message
(integer) 1
127.0.0.1:6379> RPUSH numbers 1 3 5
(integer) 3
127.0.0.1:6379> DEL numbers
(integer) 1
127.0.0.1:6379> SET key value
OK
127.0.0.1:6379> DEL key
(integer) 1

根据发回的通知显示，message、numbers、key三个键先后执行了DEL命令。服务器配置的notify-keyspace-events选项决定了服务器所发送通知的类型：

想让服务器发送所有类型的键空间通知和键事件通知，可以将选项设置为KEA
想让服务器发送所有类型的键空间通知，可以将选项设置为AK
想让服务器发送所有类型的键事件通知，可以将选项设置为AE
让服务器只和字符串键有关的键空间通知，可以将选项设置为K$
想让服务器只发送和列表键有关的键事件通知，可以将选项设置为El

关于数据库通知功能的详细用法，以及notify-keyspace-events选项的更多设置，请看Redis的官方文档

发送通知

发送数据库通知的功能由notify.c/notifyKeyspaceEvent函数实现：

void notifyKeyspaceEvent(int type, char *event, robj *key, int dbid);

函数的type参数是当前想要发送的通知的类型，程序会根据这个值来判断通知是否就是服务器配置notify-keyspace-events选项所选定的通知类型，从而决定是否发送通知。event、keys和dbid分别是事件的名称、产生事件的键，以及产生事件的数据库号码，函数会根据type参数以及三个参数来构建事件通知的内容，以及接收通知的频道名

每当一个Redis命令需要发送数据库通知的时候，该命令的实现函数就会调用notifyKeyspaceEvent函数，并向函数传递该命令所引发的事件的相关信息。例如，以下是SADD命令的实现函数saddCommand的其中一部分代码

void saddCommand(client *c) {
    ……
    //如果至少有一个元素被成功添加，那么执行以下程序
    if (added) {
        
        //发送事件通知
        notifyKeyspaceEvent(NOTIFY_SET,"sadd",c->argv[1],c->db->id);
    }
    ……
}

当SADD命令至少成功地向集合添加一个集合元素之后，命令就会发送通知，该通知的类型为REDIS_NOTIFY_SET（表示这是一个集合键通知），名称为sadd（表示这是执行SADD命令所产生的通知）

以下是另一个例子，展示了DEL命令的实现函数delCommand的其中一部分代码：

void delCommand(redisClient *c) {  
    int deleted = 0, j;  
	//遍历所有输入键
    for (j = 1; j < c->argc; j++) {  
		……
		//尝试删除键
        if (dbDelete(c->db,c->argv[j])) {  
            ……
			//删除键成功，发送通知
            notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,  
                "del",c->argv[j],c->db->id);  
            …… 
        }  
    }  
	……
}

在delCommand函数中，函数遍历所有输入键，并在删除键成功时，发送通知，通知类型为REDIS_NOTIFY_GENERIC（表示这是一个通用类型的通知），名称为del（表示这是执行del命令所产生的通知）

其他发送通知的函数调用notifyKeyspaceEvent函数的方式也和saddCommand、delCommand类似，只是给定的参数不同，接下来，我们看看notifyKeyspaceEvent函数的实现

发送通知的实现

def notifyKeyspaceEvent(type,event,key,dbid):
	#如果给定的通知不是服务器允许发送的通知，那么直接返回
	if not(server.notify_keyspace_events & type) :
	　　return
	#发送键空间通知
	if server.notify_keyspace_events & REDIS_NOTIFY_KEYSPACE:
		#将通知发送给频道__ keyspace@<dbid>__ :<key>
		#内容为键所发生的事件<event>
		#构建频道名字
		chan="keyspace@{dbid}:{key}".format(dbid=dbid,key=key)
		#发送通知
		pubsubPublishMessage(chan,event)
	#发送键事件通知
	if server.notify_keyspace_events&REDIS_NOTIFY_KEYEVENT:
		#将通知发送给频道_keyevent@<dbid>_:<event>
		#内容为发生事件的键<key>
		#构建频道名字
		chan="keyevent@{dbid}:{event}".format(dbid=dbid, event=event)
		#发送通知
		pubsubPublishMessage(chan, key)

notifyKeyspaceEvent函数执行以下操作：

server.notify_keyspace_events属性就是服务器配置notify-keyspace-events选项所设置的值，如果给定的通知事件type不是服务器允许发送的通知类型，那么函数会直接返回，不做任何操作
如果给定的通知是服务器允许发送的通知，那么下一步函数会检测服务器是否允许发送键空间的通知，如果允许的话，程序就会构建发送事件通知
最后，函数检测服务器是否允许发送事件通知，如果允许的话，程序就会构建并发送事件通知

另外pubsubPublishMessage函数时PUBLISH命令的实现函数，执行这个函数等同于执行PUBLISH命令，订阅数据库通知的客户端收到的信息就是由这个函数发出的