Redis过期键回收算法引发高延迟问题及自定义方案咨询

是否会触发循环回收占用大量资源？ #

正常情况下你描述的量级不会触发该问题，核心判断逻辑如下：

• 你每秒创建30个TTL为10分钟的键，稳态下带TTL的键总存量为 30 * 60 * 10 = 18000 个，对应总键量约5.4万。
• Redis默认每100ms执行一次主动过期回收（由配置hz默认值10控制），两次回收间隔内新过期的键仅为3个，随机抽取20个键检测时，过期键占比最高仅为15%，远低于25%的重复执行阈值，不会触发循环回收。
• 只有出现集中过期场景才会触发问题：比如你批量写入了大量设置了相同过期时间的键，到期瞬间过期键占比超过25%，才会导致回收逻辑循环执行，占用大量CPU资源。
• 你可以通过Redis命令info stats查看expired_keys指标的增长速率，info cpu查看used_cpu_sys占比，确认是否真的是过期回收导致的性能损耗。

是否可以调整回收算法的默认行为？ #

Redis不支持直接覆写默认的过期回收算法，但可以通过以下配置调整回收策略的执行逻辑：

• hz：调整主动回收的执行频率，默认值为10，最高可设置到100。值越高回收执行越频繁，单次回收占用的时间越短，适合存在大量过期键的场景，注意不要设置过高，否则后台任务会占用过多CPU资源。
• active-expire-effort：Redis 6.0及以上版本新增参数，默认值为1，取值范围1-10。值越大回收算法会投入越多CPU资源清理过期键，清理更彻底，但对应的CPU开销也会更高。
• maxmemory-policy：如果你的性能问题是内存达到上限触发被动回收导致的，可以调整该参数，比如将volatile-lru替换为allkeys-lru，避免优先淘汰带TTL的键带来的额外开销。

其他可行的优化方案 #

• 打散键的过期时间：给所有TTL添加随机偏移量，比如原本10分钟的TTL，调整为600 + 随机0~300秒，避免大量键同时到期，从根源降低过期键占比突增的概率。
• 拆分实例：如果带TTL的键总量持续增长，可以将这类非核心的短TTL键拆分到单独的Redis实例，避免回收任务影响核心业务的命令执行。
• 业务侧主动清理：访问键时提前判断有效性，主动删除已过期的无效键，减轻Redis主动回收的压力。
• 避免批量写入同TTL键：如果有批量写入的场景，必须给每个键的TTL添加随机值，不要统一设置为同一个过期时间。

内容的提问来源于stack exchange，提问作者Khosrow Yusefi