一、背景

我们都知道 Redis 是一种内存数据，所有的数据均存储在内存中，可以通过 ttl 指令查看数据的状态：

• xx：表示具有时效性的数据。
• -1：表示永久性的数据。
• -2：表示过期的数据，或已经删除的数据，或未定义的数据。

但是 过期的数据真的被删除了吗？

• 在 Redis 的执行过程中，会让 CPU 处理很多的指令，CPU 可能会一下子处理不过来，这样就需要区分优先级了。
• 很明显 Redis 的 key 过期删除操作没有那么重要，所以就先不删除，继续保存在内存中。
• 那什么时候删除呢？这就是 Redis 的删除策略做的事了。

删除策略的目标： 就是 在内存和 CPU 占用之间找到一个平衡，在 CPU 空闲的时候再去删除过期的数据，防止出现 CPU 过载导致服务器宕机、内存泄漏等问题。

---

二、Redis 的三种删除策略

Redis 有以下三种删除策略：定时删除、

2.1 定时删除（用CPU换内存空间）

实现方式： 创建一个定时器，每间隔一段时间，定时器会 对全量 key 的扫描，并删除过期的 key。

• 优点： 节约内存，可以定期立即释放掉所有不必要的内存空间。
• 缺点： CPU 的压力会很大，不会考虑删除的时候 CPU 是否空闲，会影响 Redis 服务器的响应时间和吞吐量。
• 应用场景： 适用于对数据过期时间要求不高，数据量较小的场景。

2.2 定期删除

实现方式： 由 redis.c 的 activeExpireCycle() 函数实现，周期性轮询 Redis 库中的时效性数据，采用随机抽取策略，利用过期数据占比的方式控制删除的频率。

• Redis 启动服务器初始化时，读取配置 server.hz 的值，默认为10。
• 每秒钟执行 server.hz 次 serverCron() -> databaseCron() -> activeExpireCycle()。
• activeExpireCycle() 对每个 expires[*] 逐一进行检测，每次执行 250ms/server.hz。
• 对某个 expires[*] 检测时，随机挑选 W 个 key 检测：
  • 如果key超时，删除 key；
  • 如果一轮中删除的 key 的数量 > W * 25%，循环该过程；
  • 如果一轮中删除的 key 的数量 ≤ W * 25%，检查下一个 expires[*]，0~15循环；
  • W 取值 = ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 属性值。
• 参数 current_db 用于记录 activeExpireCycle() 进入了哪个 expires[*] 执行。
• 如果 activeExpireCycle() 执行时间到期，下次从 current_db 继续向下执行。

• 优点：
  1. CPU 性能占用设置有峰值，检测频率可自定义设置，相对于定时删除，可以更灵活地控制 CPU占用，适用于数据量较大的情况。
  2. 内存压力不是很大，长期占用内存的冷数据会被持续清理。
• 缺点： 可能会导致短时间内部分内存无法及时释放，对系统性能有一定影响。
• 应用场景： 适用于数据量较大、对内存占用没有特别要求的场景。

补充： 定期删除函数的运行频率，在 Redis 2.6 版本中，规定每秒运行 10次，大概 100ms 运行一次。在 Redis 2.8 版本后，可以通过修改配置文件 redis.conf 的 hz 选项来调整这个次数。

2.3 惰性删除（用内存换CPU性能）

实现方式： 数据到达过期时间，不做处理。等下次访问该数据时，发现未过期，则返回值，发现已经过期，删除 expires 空间和 key 值，并返回不存在。

• 优点： 节约 CPU 性能，当数据必须删除的时候才删除。
• 缺点： 内存压力较大，会出现过期数据长期占用内存的情况。
• 应用场景： 适用于对数据过期时间要求不严格、对内存占用要求宽松的场景。

---

三、总结

Redis 采用的是 定期删除 + 惰性删除 的策略。

注意：删除策略只是一种策略，在 Redis 并 不能通过修改配置文件的方式进行切换，Redis 中删除策略的具体实现是通过 内存淘汰机制 实现。

整理完毕，完结撒花~🌻

参考地址：

1.Redis删除策略，https://blog.csdn.net/xiaobai_mantou/article/details/107191137
2.Redis中常见的三种删除策略，https://blog.csdn.net/qq_44577699/article/details/134965409
3.Redis删除策略详解和Redis核心配置（简单详细，谁看谁知道），https://www.cnblogs.com/lxl01/p/14995601.html