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定期删除过期有两种模式：快模式和慢模式(默认)
  注意：

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

默认进入慢模式：
(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插入两组数据

现在对第二组数据执行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.为什么不能用过期事件功能：用事件通知删除。