实现redis的key失效所引发的一系列问题

如何实现redis的key失效， 主动失效的流程，如何保证下一轮可以继续上一轮的检测，默认的通过检验的比例是多少，让你来实现，你打算怎么做。

1.通过设置过期时间使redis的key失效   EXPIRE key 30 上面的命令即为key设置30秒的过期时间，超过这个时间，我们应该就访问不到这个值了，到此为止我们大概明白了什么是缓存失效机制以及缓存失效机制的一些应用场景，接下来我们继续深入探究这个问题，Redis缓存失效机制是如何实现的呢？ 延迟失效机制（非重点） 延迟失效机制即当客户端请求操作某个key的时候，Redis会对客户端请求操作的key进行有效期检查，如果key过期才进行相应的处理，延迟失效机制也叫消极失效机制。我们看看t_string组件下面对get请求处理的服务端端执行堆栈： getCommand      -> getGenericCommand             -> lookupKeyReadOrReply                    -> lookupKeyRead                          -> expireIfNeeded 关键的地方是expireIfNeed，Redis对key的get操作之前会判断key关联的值是否失效，这里先插入一个小插曲，我们看看Redis中实际存储值的地方是什么样子的： 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对于的值删除。 主动失效机制( 重点 )    主动失效机制也叫积极失效机制，即服务端定时的去检查失效的缓存，如果失效则进行相应的操作。 我们都知道Redis是单线程的，基于事件驱动的，Redis中有个EventLoop，EventLoop负责对两类事件进行处理： 一类是IO事件，这类事件是从底层的多路复用器分离出来的。 一类是定时事件，这类事件主要用来事件对某个任务的定时执行。 看起来Redis的EventLoop和Netty以及JavaScript的EventLoop功能设计的大概类似，一方面对网络I/O事件处理，一方面还可以做一些小任务。 为什么讲到Redis的单线程模型，因为Redis的主动失效机制逻辑是被当做一个定时任务来由主线程执行的，相关代码如下： 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做的事情有点多，我们只关心和本篇内容相关的部分，也就是缓存失效是怎么实现的，我认为看代码做什么事情，调用堆栈还是比较直观的： aeProcessEvents     ->processTimeEvents         ->serverCron              -> databasesCron                    -> activeExpireCycle                            -> activeExpireCycleTryExpire EventLoop通过对定时任务的处理，触发对serverCron逻辑的执行，最终之执行key过期处理的逻辑，值得一提的是，activeExpireCycle逻辑只能由master来做。 遗留问题 Redis对缓存失效的处理机制大概分为两种，一种是客户端访问key的时候消极的处理，一种是主线程定期的积极地去执行缓存失效清理逻辑，上面文章对于一些细节还没有展开介绍，但是对于Redis缓存失效实现机制这个话题，本文留下几个问题： Redis缓存失效逻辑为什么只有master才能操作？ 上面提到如果客户端访问的是slave，slave并不会清理失效缓存，那么这次客户端岂不是获取了失效的缓存？ 上面介绍的两种缓存失效机制各有什么优缺点？Redis设计者为什么这么设计？ 服务端对客户端的请求处理是单线程的，单线程又要去处理失效的缓存，是不是会影响Redis本身的服务能力？ 缓存失效逻辑为什么只有master才能操作http://blog.sina.com.cn/s/blog_48c95a190101e5hv.html 这里需要说明的是在expireIfNeeded函数中调用的另外一个函数propagateExpire，这个函数用来在正式删除失效主键之前广播这个主键已经失效的信息，这个信息会传播到两个目的地：一个是发送到AOF文件，将删除失效主键的这一操作以DEL Key的标准命令格式记录下来；另一个就是发送到当前Redis服务器的所有Slave，同样将删除失效主键的这一操作以DEL Key的标准命令格式告知这些Slave删除各自的失效主键。从中我们可以知道，所有作为Slave来运行的Redis服务器并不需要通过消极方法来删除失效主键，它们只需要对Master唯命是从就OK了！ 服务端对客户端的请求处理是单线程的，单线程又要去处理失效的缓存，是不是会影响Redis本身的服务能力？ Redis 的主键失效机制对系统性能的影响 Redis 会定期地检查设置了失效时间的主键并删除已经失效的主键，但是通过对每次处理数据库个数的限制、activeExpireCycle 函数在一秒钟内执行次数的限制、分配给 activeExpireCycle 函数CPU时间的限制、继续删除主键的失效主键数百分比的限制，Redis 已经大大降低了主键失效机制对系统整体性能的影响，但是如果在实际应用中出现大量主键在短时间内同时失效的情况还是会产生很多问题， 也就是缓存穿透的情况。 上面提到如果客户端访问的是slave，slave并不会清理失效缓存，那么这次客户端岂不是获取了失效的缓存？ 这 里需要说明的是在expireIfNeede d函数中调用的另外一个函数propagateExpire，这个函数用来在正式删除失效主键之前广播这个主键已经 失效的信息 ，这个信息会传 播到两个目的地：一个是发送到AOF文件，将删除失效主键的这一操作以DEL Key的标准命令格 式记录下来； 另一个就是发送到当前Redis服务器的所有Slave，同样 将删除失 效主键的这一操作以DEL Key的标准命令 格式告知这些 Slave删除各自的失效主键。从中我们可以知道，所有作为Slave来运 行的Redis服务器 并不需要通过消极方法来删除失效主键，它们只需要对Master唯命 是从就OK了 ！ 代码段二：    int expireIfNeeded(redisDb *db, robj *key) {      获取主键的失效时间     long long when = getExpire(db,key);      假如失效时间为负数，说明该主键未设置失效时间（失效时间默认为-1），直接返回0     if (when < 0) return 0;      假如Redis服务器正在从RDB文件中加载数据，暂时不进行失效主键的删除，直接返回0     if (server.loading) return 0;      假如当前的Redis服务器是作为Slave运行的，那么不进行失效主键的删除，因为Slave     上失效主键的删除是由Master来控制的，但是这里会将主键的失效时间与当前时间进行     一下对比，以告知调用者指定的主键是否已经失效了     if (server.masterhost != NULL) {         return mstime() > when;     }      如果以上条件都不满足，就将主键的失效时间与当前时间进行对比，如果发现指定的主键     还未失效就直接返回0     if (mstime() <= when) return 0;      如果发现主键确实已经失效了，那么首先更新关于失效主键的统计个数，然后将该主键失     效的信息进行广播，最后将该主键从数据库中删除     server.stat_expiredkeys++;     propagateExpire(db,key);     return dbDelete(db,key); } 代码段三： void propagateExpire(redisDb *db, robj *key) {     robj *argv[2];      shared.del是在Redis服务器启动之初就已经初始化好的一个常用Redis对象，即DEL命令     argv[0] = shared.del;     argv[1] = key;     incrRefCount(argv[0]);     incrRefCount(argv[1]);      检查Redis服务器是否开启了AOF，如果开启了就为失效主键记录一条DEL日志     if (server.aof_state != REDIS_AOF_OFF)         feedAppendOnlyFile(server.delCommand,db->id,argv,2);      检查Redis服务器是否拥有Slave，如果是就向所有Slave发送DEL失效主键的命令，这就是     上面expireIfNeeded函数中发现自己是Slave时无需主动删除失效主键的原因了，因为它     只需听从Master发送过来的命令就OK了     if (listLength(server.slaves))         replicationFeedSlaves(server.slaves,db->id,argv,2);     decrRefCount(argv[0]);     decrRefCount(argv[1]); } 遗留问题解答 redis的三种过期策略 定时删除 含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除 优点：保证内存被尽快释放 缺点： 若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key 定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重 没人用 惰性删除 含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。 优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了） 缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存） 定期删除 含义：每隔一段时间执行一次删除过期key操作。即每隔一段时间就中断一下完成一些指定操作，其中就包括检查并删除失效主键。 优点： 通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点 定期删除过期key--处理"惰性删除"的缺点 缺点 在内存友好方面，不如"定时删除" 在CPU时间友好方面，不如"惰性删除" 难点 合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了） 注意： 上边所说的数据库指的是内存数据库，默认情况下每一台redis服务器有16个数据库（关于数据库的设置，看下边代码），默认使用0号数据库，所有的操作都是对0号数据库的操作，关于redis数据库的存储结构，查看 第八章 Redis数据库结构与读写原理 # 设置数据库数量。默认为16个库，默认使用DB 0，可以使用"select 1"来选择一号数据库 # 注意：由于默认使用0号数据库，那么我们所做的所有的缓存操作都存在0号数据库上， # 当你在1号数据库上去查找的时候，就查不到之前set过得缓存 # 若想将0号数据库上的缓存移动到1号数据库，可以使用"move key 1" databases 16 memcached只是用了惰性删除，而redis同时使用了惰性删除与定期删除，这也是二者的一个不同点（可以看做是redis优于memcached的一点） 对于惰性删除而言，并不是只有获取key的时候才会检查key是否过期，在某些设置key的方法上也会检查（eg.setnx key2 value2：该方法类似于memcached的add方法，如果设置的key2已经存在，那么该方法返回false，什么都不做；如果设置的key2不存在，那么该方法设置缓存key2-value2。假设调用此方法的时候，发现redis中已经存在了key2，但是该key2已经过期了，如果此时不执行删除操作的话，setnx方法将会直接返回false，也就是说此时并没有重新设置key2-value2成功，所以对于一定要在setnx执行之前，对key2进行过期检查）   3、Redis采用的过期策略 惰性删除+定期删除 惰性删除流程 在进行get或setnx等操作时，先检查key是否过期， 若过期，删除key，然后执行相应操作； 若没过期，直接执行相应操作 定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key） 遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16） 检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述） 如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历 随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key 判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。 注意： 对于定期删除，在程序中有一个全局变量current_db来记录下一个将要遍历的库，假设有16个库，我们这一次定期删除遍历了10个，那此时的current_db就是11，下一次定期删除就从第11个库开始遍历，假设current_db等于15了，那么之后遍历就再从0号库开始（此时current_db==0） 由于在实际中并没有操作过定期删除的时长和频率，所以这两个值的设置方式作为疑问？   4、RDB对过期key的处理 过期key对RDB没有任何影响 从内存数据库持久化数据到RDB文件 持久化key之前，会检查是否过期，过期的key不进入RDB文件 从RDB文件恢复数据到内存数据库 数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）   5、AOF对过期key的处理 过期key对AOF没有任何影响 从内存数据库持久化数据到AOF文件： 当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令） 当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉） AOF重写 重写时，会先判断key是否过期，已过期的key不会重写到aof文件                                                                                    源码层面的失效实现 Redis 删除失效主键的方法主要有两种： 消极方法（passive way），在主键被访问时如果发现它已经失效，那么就删除它 积极方法（active way），周期性地从设置了失效时间的主键中选择一部分失效的主键删除 主键具体的失效时间全部都维护在expires这个字典表中。 1 2 3 4 5 6 7 8 typedef struct redisDb {      dict *dict;  //key-value      dict *expires;   //维护过期key      dict *blocking_keys;      dict *ready_keys;      dict *watched_keys;      int  id; } redisDb;   （1）passive way 消极方法 在passive way 中， redis在实现GET、MGET、HGET、LRANGE等所有涉及到读取数据的命令时都会调用 expireIfNeeded，它存在的意义就是在读取数据之前先检查一下它有没有失效，如果失效了就删除它。 expireIfNeeded函数中调用的另外一个函数propagateExpire，这个函数用来在正式删除失效主键之前广播这个主键已经失效的信息，这个信息会传播到两个目的地： 一个是发送到AOF文件，将删除失效主键的这一操作以DEL Key的标准命令格式记录下来； 另一个就是发送到当前Redis服务器的所有Slave，同样将删除失效主键的这一操作以DEL Key的标准命令格式告知这些Slave删除各自的失效主键。从中我们可以知道，所有作为Slave来运行的Redis服务器并不需要通过消极方法来删除失效主键，它们只需要执行Master的删除指令即可。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18