Redis缓存失效机制-详细内容

文章内容

2017/9/29 9:36:59,作者: 黄兵

Redis缓存失效机制

Redis缓存失效的故事要从EXPIRE这个命令说起，EXPIRE允许用户为某个key指定超时时间，当超过这个时间之后key对应的值会被清除，这篇文章主要在分析Redis源码的基础上站在Redis设计者的角度去思考Redis缓存失效的相关问题。

一、Redis缓存失效机制

通常Redis keys创建时没有设置相关过期时间。他们会一直存在，除非使用显示的命令移除，例如，使用DEL命令。EXPIRE一类命令能关联到一个有额外内存开销的key。当key执行过期操作时，Redis会确保按照规定时间删除他们。key的过期时间和永久有效性可以通过EXPIRE和PERSIST命令（或者其他相关命令）来进行更新或者删除过期时间。

为给定key设置生存时间，当key过期时(生存时间为0)，它会被自动删除。在Redis中，带有生存时间的key被称为『易失的』(volatile)。生存时间可以通过使用DEL命令来删除整个key来移除，或者被SET和GET/SET命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的key的值而不是用一个新的key值来代替(replace)它的话，那么生存时间不会被改变。比如说，对一个key执行INCR命令，对一个列表进行LPUSH命令，或者对一个哈希表执行HSET命令，这类操作都不会修改key本身的生存时间。

另一方面，如果使用RENAME对一个key进行改名，那么改名后的key的生存时间和改名前一样。RENAME命令的另一种可能是，尝试将一个带生存时间的key改名成另一个带生存时间的another_key，这时旧的another_key(以及它的生存时间)会被删除，然后旧的key会改名为another_key，因此，新的another_key的生存时间也和原本的key一样。

使用PERSIST命令可以在不删除key的情况下，移除key的生存时间，让key重新成为一个『持久的』(persistent) key 。

redis> SET cache_page "www.google.com" OK

redis> EXPIRE cache_page 30 #设置过期时间为30秒 (integer) 1

redis> TTL cache_page #查看剩余生存时间 (integer) 23

redis> EXPIRE cache_page 30000 #更新过期时间 (integer) 1

redis> TTL cache_page (integer) 29996

1）在小于2.1.3的redis版本里，只能对key设置一次expire。redis2.1.3和之后的版本里，可以多次对key使用expire命令，更新key的expire time。

2）Redis术语里面，把设置了expire time的key叫做：volatile keys，意思就是不稳定的key。

3）如果对key使用set或del命令，那么也会移除expire time。尤其是set命令，这个在编写程序的时候需要注意一下。

4）Redis 2.1.3之前的老版本里，如果对volatile keys做相关写入操作(LPUSH,LSET)，和其他一些触发修改value的操作时，redis会删除该key。

5）Redis对过期键采用了lazy expiration：在访问key的时候判定key是否过期，如果过期，则进行过期处理。其次，每秒对volatile keys进行抽样测试，如果有过期键，那么对所有过期key进行处理。

到此为止我们大概明白了什么是缓存失效机制以及缓存失效机制的一些应用场景，接下来我们继续深入探究这个问题，Redis缓存失效机制是如何实现的呢？

二、Redis如何淘汰过期的keys

2.1 延迟失效机制

延迟失效机制即当客户端请求操作某个key的时候，Redis会对客户端请求操作的key进行有效期检查，如果key过期才进行相应的处理，延迟失效机制也叫消极失效机制。我们看看t_string组件下面对get请求处理的服务端端执行堆栈：

1
2
3
4
5
getCommand 
    -> getGenericCommand 
        -> lookupKeyReadOrReply 
            -> lookupKeyRead 
                -> expireIfNeeded

关键的地方是expireIfNeed，Redis对key的get操作之前会判断key关联的值是否失效，这里先插入一个小插曲，我们看看Redis中实际存储值的地方是什么样子的：

1
2
3
4
5
6
7
8
9
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

上面是Redis中定义的一个结构体，dict是一个Redis实现的一个字典，也就是每个DB会包括上面的五个字段，我们这里只关心两个字典，一个是dict，一个是expires：

dict是用来存储正常数据的，比如我们执行了set key “hahaha”，这个数据就存储在dict中。
expires使用来存储关联了过期时间的key，比如我们在上面的基础之上有执行的expire key 1，这个时候就会在expires中添加一条记录。

回过头来看看expireIfNeeded的流程，大致如下：

从expires中查找key的过期时间，如果不存在说明对应key没有设置过期时间，直接返回。
如果是slave机器，则直接返回，因为Redis为了保证数据一致性且实现简单，将缓存失效的主动权交给Master机器，slave机器没有权限将key失效。
如果当前是Master机器，且key过期，则Master会做两件重要的事情：1）将删除命令写入AOF文件。2）通知Slave当前key失效，可以删除了。
Master从本地的字典中将key对应的值删除。

2.2 主动失效机制

主动失效机制也叫积极失效机制，即服务端定时的去检查失效的缓存，如果失效则进行相应的操作。

我们都知道Redis是单线程的，基于事件驱动的，Redis中有个EventLoop，EventLoop负责对两类事件进行处理：

一类是IO事件，这类事件是从底层的多路复用器分离出来的。
一类是定时事件，这类事件主要用来事件对某个任务的定时执行。

看起来Redis的EventLoop和Netty以及JavaScript的EventLoop功能设计的大概类似，一方面对网络I/O事件处理，一方面还可以做一些小任务。

为什么讲到Redis的单线程模型，因为Redis的主动失效机制逻辑是被当做一个定时任务来由主线程执行的，相关代码如下：

1
2
3
4
if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
        redisPanic("Can't create the serverCron time event.");
        exit(1);
    }

serverCron就是这个定时任务的函数指针，adCreateTimeEvent将serverCron任务注册到EventLoop上面，并设置初始的执行时间是1毫秒之后。接下来，我们想知道的东西都在serverCron里面了。serverCron做的事情有点多，我们只关心和本篇内容相关的部分，也就是缓存失效是怎么实现的，我认为看代码做什么事情，调用堆栈还是比较直观的：

1
2
3
4
5
6
aeProcessEvents
    ->processTimeEvents
        ->serverCron 
             -> databasesCron 
                   -> activeExpireCycle 
                           -> activeExpireCycleTryExpire