Redis key过期策略

2019-04-12 posted in [学习笔记]

Redis所有的数据结构都可以设置过期时间，到期后，key会被自动删除。

Redis key过期的方式有三种：

只有key被操作时（如GET），Redis才会被动检查该key是否过期，过期就删除，并返回NULL。

这种删除策略对CPU友好，不会在删除上浪费无谓的CPU时间。然而这种策略对内存不友好，一个key已经过期，但是在它被操作之前不会被删除，仍然占据内存空间。如果系统中存在大量的不会被访问的数据，就会造成资源浪费。

Redis会把有过期时间的key放在一个单独的字典里，默认每100ms检查，是否有过期的key，有过期的key则删除。

这里不是每100ms把所有key检查一次，而是随机抽取检查。典型的方式为，Redis每秒做10次如下的步骤：

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，Redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4。

除了主动淘汰的频率外，Redis对每次淘汰任务执行的最大时长也有一个限定，这样保证了每次主动淘汰不会过多阻塞应用请求。

当Redis启用主从模式时，只有主结点执行上述这两种过期删除策略。主节点在key到期时，会在AOF文件里增加一条DEL指令，同步到所有的从节点，从节点通过执行这条del指令来删除过期的key。

当Redis实例的内存超过设置的maxmemory时，会根据配置的策略maxmemory-policy来对key进行淘汰，可选的淘汰策略有如下几种：

线上的所有Reids实例默认的淘汰策略为volatile-lru。

上述策略可以在redis.conf中配置。

其他处理key过期

执行SAVE或BGSAVE时，数据库键空间中的过期键不会被保存在RDB文件中。

Master载入RDB时，文件中的未过期的键会被正常载入，过期键则会被忽略。 Slave载入RDB时，文件中的所有键都会被载入，当同步进行时，会和Master保持一致。

数据库键空间的过期键的过期但并未被删除释放的状态会被正常记录到AOF文件中，当过期键发生释放删除时，DEL也会被同步到AOF文件中去。

执行BGREWRITEAOF时，数据库键中过期的键不会被记录到AOF文件中

Master删除过期key之后，会向所有Slave服务器发送一个DEL命令，从服务器收到之后，会删除这些key。

Slave在被动的读取过期键时，不会做出操作，而是继续返回该键，只有当Master发送DEL通知来，才会删除过期键，这是统一、中心化的键删除策略，保证主从服务器的数据一致性。

由于Slave不会主动删除过期key，对于做了读写分离的业务，有可能导致从库读取到过期的脏数据。

代码如下：（5.0版本，在db.c中）

这是因为key的过期删除依赖于expireIfNeeded函数，这个函数在任何访问数据的操作中都会被调用并用来检测客户端访问的数据是否过期。

代码第一行就判断了是否过期，如果未过期，直接返回0。

已过期的情况下，如果当前数据库实例角色是Slave，则不进行key过期的删除操作，直接返回1；如果当前数据库实例角色是Master，则首先更新关于失效主键的统计个数，然后将该主键失效的信息进行广播，最后将该主键从Redis中删除。

通过scan命令扫库：

当Redis中的key被scan的时候，相当于访问了该key，同样也会做过期检测，充分发挥Redis惰性删除的策略。这个方法能大大降低了脏数据读取的概率，但缺点也比较明显，会造成一定的数据库压力，谨慎合理使用，否则有可能影响线上业务的效率。
升级Redis到新的版本：

在redis 3.2-rc1版本中，增加了key是否过期以及对主从库的判断，如果key已过期，当前访问的是Master则返回NULL；当前访问的是从库，且执行的是只读命令也返回NULL（老版本从库真实的返回该操作的结果，如果该key过期后主库没有删除）。

–EOF–