Redis“垃圾”过期死键管理与优化

【作者】付磊

Redis死键的定义不尽相同，通常有两种：

• 写到Redis里后，由于过期时间过长或者压根没有过期时间，加之长期不访问，这类key可以被称为死键。

• 明明已经过了过期时间，但还占用Redis内存（没有真的删除），这类key也可以被称为死键。

注：本文讨论第二种情况

一、两个例子

下面两个列子中的键值均有过期时间，同时有些键值已过期

1. 对某Redis集群进行全量scan后，键值数和容量的变化：

	键值数	容量GB
扫描前	5,628,636,513	1116
扫描后	4,206,662,303	798

2. 两个同名不同版本的Redis集群的键值数和容量(全部为string类型)

版本	键值数	容量GB
Redis 4.0.14	821,131,528	831
Redis 6.0.15	821,131,528	433

初步结论：

• scan操作可能会加速Redis的过期键值删除。

• Redis 6版本比Redis 4在同等数据下更节省空间，考虑到Redis成本优化-版本升级-1.SDS优化历史一文中提到4.0~7.0字符串类型在容量上并没有过多优化，因此初步判定Redis 6可能在过期上做过优化

二、基础知识-Redis过期

1. Redis过期数据怎么存？

每个Redis有多个redisDb(但正常只用db0)，每个redisDb包含两个dict：dict存key-value、expires存key的过期时间

typedef?struct?redisDb?{
????dict?*dict;?????????????????/*?The?keyspace?for?this?DB?*/
????dict?*expires;??????????????/*?Timeout?of?keys?with?a?timeout?set?*/
????...
}?redisDb;

具体如图所示

(1) 正常的dict图：（该图来自《Redis设计与实现》）

(2) 抽象的表现dict和expires表可以使用如下图：(来源于google图片)

再次借个图：expires中key stringobject和dict中的 key stringobject是同一个：

2. Redis过期策略

由于Redis单线程(work thread)的特性，如果精准实时删除每个过期键值，会耗费大量CPU。所以Redis折中实现两种过期删除策略：惰性删除和定期删除。

(1) 惰性删除

客户端执行key相关命令时(以get为例子)，首先会去检测key是否在expires表里：

• 如果在expires表里

  • 如果已经过期：直接删除，并返回空

  • 如果没有过期：从dict表里获取value

• 如果不在expires表里，从dict表里获取value

(2) 定期删除

惰性删除的问题是依赖于主动访问，如果一直不访问，数据将长期保存，造成内存浪费，于是需要添加新的策略：定期删除。

Redis会每100毫秒(如果hz默认是10)，会对expires表中已过期数据进行自适应算法删除(具体方法下面会详细介绍)。

三、Redis版本优化

为了更生动的表现Redis 6在死键上的升级，可以做如下实验：写入500万条string，key和value都是16字节，过期时间在1-18秒

版本	全部数据过期耗时
Redis 4.0.14	38262ms
Redis 6.0.15	19267ms

1. Redis 6.0之前：

Redis定期删除过期有两种模式：快模式和慢模式(默认)

注意：
1. 快模式：希望每次定期删除快速结束，防止占用Redis处理正常命令的CPU。
2. 快模式和慢模式在执行过程中自适应的进行转换，本质都是防止占用Redis处理正常命令的CPU。
3. 快模式和慢模式：只是超时时间不同，删除逻辑是一样的

默认进入慢模式：

(1) 循环遍历全部redisDb，随机抽取20个键值，如果发现过期就直接删除。

(2) 判断20个键值中的25%(也就是5个)是否过期

• 如果小于等于25%，则退出当前redisDb的循环，继续下一个redisDb

• 如果大于25%，继续抽取20个键值进行循环，每次判断总的执行时间是否超过25毫秒

  • 超过25毫秒，过期进入快模式(超时时间会变短)

  • 没超过25毫秒，则退出当前redisDb的循环，继续下一个redisDb

几个重要参数：

#define?ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP?20?/*?上述的20个键值?*/
#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /*?慢模式超时时间：25%的CPU时间?*/
#define ACTIVE_EXPIRE_CYCLE_FAST_DURATION 1000?/*?快模式超时时间：1ms */

2. Redis 6.0优化

(1) 每次随机-->记录遍历游标

Redis 6.0之前每次执行定期删除都是随机抽取20个键值，如果当前Redis有过期时间的键值数量较多(例如几百万、几千万)，那么这个随机会导致很多key不会被扫描到，因此在Redis 6.0中在redisDb加了一个游标(expires_cursor)，记录上一次扫描的位置，可以保证最终全部的键值会被扫描到，有效的提升效率。

typedef?struct?redisDb?{
????dict?*dict;?????????????????/*?The?keyspace?for?this?DB?*/
????dict?*expires;??????????????/*?Timeout?of?keys?with?a?timeout?set?*/
????unsigned?long?expires_cursor;?/*?Cursor?of?the?active?expire?cycle.?*/
???.......
}?redisDb;

(2) 判断20个键值中的25%(也就是5个)-->10%(也就是2个)

Before 6.0：

do?{
???num?=?ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP
???while?(num--)?{
????????//检测每个key的过期时间，并做相关记录，如果已经过期expired++
????}
}?while?(expired?>?ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP/4);

After 6.0，config_cycle_acceptable_stale可调配

do?{
???num?=?ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP
???while?(num--)?{
????????//检测每个key的过期时间，并做相关记录，如果已经过期expired++
????}
}
}?while?((expired*100/sampled)?>?config_cycle_acceptable_stale);

(3) 添加增强系数

新增active_expire_effort配置，可以适当增强定期删除粒度，它的值范围在1-10。

unsigned?long?effort?=?server.active_expire_effort-1,?/*?Rescale?from?0?to?9.?*/
//增加每次扫描key的个数
config_keys_per_loop?=?ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP?+??ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP/4*effort,
//增加快模式的超时时间
config_cycle_fast_duration?=?ACTIVE_EXPIRE_CYCLE_FAST_DURATION?+??ACTIVE_EXPIRE_CYCLE_FAST_DURATION/4*effort,
//增加慢模式的超时时间
config_cycle_slow_time_perc?=?ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC?+?2*effort,
//上述while中的比率
config_cycle_acceptable_stale?=?ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE-?effort;

四、为什么会有死键、危害是什么

1. 为什么会有死键

(1) 惰性删除：如果很多key不会被二次访问，就会产生死键

(2) 定期删除：如果过期键值生产速度大于定期删除速度

针对(2)有两种情况：

第一种：当前Redis有大量写入同时键值过期时间都很短。

第二种：当前Redis包含大量键值(例如百万级别)，但已经过期的数据只占很小的比率，这种相对诡异。

我们还是举个例子：线上某集群

	键值数Million	容量GB
扫描前	991.18	396.37
扫描后	814.58	296.90

我们可以分析它的键值空间：短过期时间只占很少的比率，它无法自行完成死键的快速过期。

我们回到之前分析的流程图就很容易得出答案：每次遍历redisdb有个核心条件是是否超过25%的键值过期了，从上面的键值分析图可以判断，每次扫描大部分可能就循环一次。

2.死键的危害

危害本质：例如当前集群100GB, 键值如果没有死键只有50G，如果有死键可能就是90GB。

(1) 增加运维次数：业务侧可能会频繁提交扩容。

(2) 浪费成本：

(3) 可能产生逐出：不可预期的使用容量，可能会造成数据逐出(大部分逐出算法都是近似算法，例如lru)

五、如何解决

关于这个比较有意思的是看到官方给出的一个方法是重启，这个对线上环境不太现实(即使有failover)。我们在生产中可以使用如下方法：

1.适度调整active_expire_effort参数(针对Redis 6.0+)

怎么叫适度呢？我们要理解本质上Redis是要对外提供服务的，所以我们必须保证有足够多的CPU时间给正常的命令访问，Redis 4.0之后有个核心指标stat_expired_time_cap_reached_count可以作为参考，其实它就是记录了超时次数，代表在过期删除上投入过多CPU时间。

/*?We?can't?block?forever?here?even?if?there?are?many?keys?to
?*?expire.?So?after?a?given?amount?of?milliseconds?return?to?the
?*?caller?waiting?for?the?other?active?expire?cycle.?*/
if?((iteration?&?0xf)?==?0)?{?/*?check?once?every?16?iterations.?*/
????elapsed?=?ustime()-start;
????if?(elapsed?>?timelimit)?{
????????timelimit_exit?=?1;
????????server.stat_expired_time_cap_reached_count++;
????????break;
????}
}

可以对齐进行监控。

2.定期scan

当识别到某些集群有如下特点，可以借助外力scan（其实就是惰性删除）帮助过期键值数据删除，但是也要力度适度，例如要结合当前Redis的CPU繁忙程度进行sleep时间设定。

3. hz:

这个建议不要乱调整。。hz影响的地方不止这个，所以不要乱调（网上各种文章让调整这个，一定要慎重）

六、如何识别？

说句实话这个问题比较复杂，我也琢磨了挺长时间，可以大概归结成6点（欢迎大佬来喷）

1.expires表要“大”：

需要有一定规模(不然死键问题不存在)，一般认为超过100万（但这个不绝对，比如第2中情况）

2.批量生成大量短过期时间的键值：

avg_ttl的例子如下：

键值分析的效果如下：

3.avg_ttl不可靠

avg_ttl是一个近似值，同时它会受到非常长过期时间的干扰（俗称“被平均”），上述中例子就是个典型，avg_ttl是15day，但是确实包含了大量死键

4.利用stat_expired_time_cap_reached_count定位

stat_expired_time_cap_reached_count比较频繁说明过期键值很多，因为已经超时了，可以把全部实例绘图监控或者告警

5.键值分析结合stat_expired_stale_perc指标

stat_expired_stale_perc是total_expired/total_sampled的近似比率，如果偏高说明过期键值很多，如果偏低，需要结合键值分析看是否受到了整体的干扰。

double?current_perc;
if?(total_sampled)?{
????current_perc?=?(double)total_expired/total_sampled;
}?else
????current_perc?=?0;
server.stat_expired_stale_perc?=?(current_perc*0.05)+
?????????????????????????????????(server.stat_expired_stale_perc*0.95);

6. 终极绝招：scan后给集群打标签

低峰期对每个可疑集群进行清理scan，记录前后键值容量变化，对集群进行标签后，开启定期scan

请控制好redis实例的键值个数

参考Redis开发规范解析(三)--一个Redis最好存多少key

七、最后一个小实验

如何证明expires中的key和dict中的key是同一个。

实验：在Redis 6.0.15插入两组数据

key数量	键值	过期时间	used_memory_human
500万	string类型，key和value都是16字节	不过期	598.158MB
500万	string类型，key和value都是16字节	过期时间1天	776.599MB
			多出：178.44MB

现在对第二组数据执行debug htstats

127.0.0.1:12615>?debug?HTSTATS?0
[Dictionary?HT]
Hash?table?0?stats?(main?hash?table):
?table?size:?8388608
?number?of?elements:?5000000
?different?slots:?3766504
?max?chain?length:?10
?avg?chain?length?(counted):?1.33
?avg?chain?length?(computed):?1.33
?Chain?length?distribution:
???0:?4622104?(55.10%)
???1:?2755189?(32.84%)
???2:?820438?(9.78%)
???3:?163161?(1.95%)
???4:?24475?(0.29%)
???5:?2930?(0.03%)
???6:?278?(0.00%)
???7:?32?(0.00%)
???10:?1?(0.00%)
[Expires?HT]
Hash?table?0?stats?(main?hash?table):
?table?size:?8388608
?number?of?elements:?5000000
?different?slots:?3766504
?max?chain?length:?10
?avg?chain?length?(counted):?1.33
?avg?chain?length?(computed):?1.33
?Chain?length?distribution:
???0:?4622104?(55.10%)
???1:?2755189?(32.84%)
???2:?820438?(9.78%)
???3:?163161?(1.95%)
???4:?24475?(0.29%)
???5:?2930?(0.03%)
???6:?278?(0.00%)
???7:?32?(0.00%)
???10:?1?(0.00%)

下面分别计算：

(1) table size: 8388608，每个需要8个字节指针 ?= 8388608 * 8 / 1024 / 1024 = 64MB

(2) number of elements: 5000000，刨除dictEntry中的key(这里假设是共享的)，value = 16字节（一个int编码的redisobj，为什么是16字节(redis 6)，请参考Redis成本优化-版本升级-1.SDS优化历史加上一个8字节next指针，最终折合=5000000 * (16 + 8 ) /1024/1024=114.44MB

最终我们可以验证expires中的key和dict中的key是共享的。

八、几个思考

1.为什么Redis的过期不能立即删除

2.为什么不能用过期事件功能：用事件通知删除。