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

【作者】付磊

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

写到Redis里后，由于过期时间过长或者压根没有过期时间，加之长期不访问，这类key可以被称为死键。
明明已经过了过期时间，但还占用Redis内存（没有真的删除），这类key也可以被称为死键。

注：本文讨论第二种情况

一、两个例子

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

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

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

两个同名不同版本的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.为什么不能用过期事件功能：用事件通知删除。