Redis内存清理别太激进，调整策略让性能更稳一点

Redis这个内存数据库,速度快是它的招牌，但内存毕竟是有限的，当内存快用完时，就得清理掉一些数据来腾出空间，这个清理过程，如果搞得太猛、太突然，就像为了打扫房间把所有东西瞬间清空一样，很容易让Redis本身“卡住”，导致正在使用的应用程序突然感觉Redis变慢了，甚至超时出错，我们不能让内存清理变得太激进，得找一些更温和、更平稳的策略。

得明白Redis清理内存的几种主要方式,根据其官方文档和社区常见解读，Redis的内存回收策略大致分两种：一种是靠代码里设置的过期时间，到点自动删除；另一种是当内存达到上限时，触发淘汰机制，按照一定规则移除某些键。

问题往往出在第一种——过期键的删除上，如果Redis里同时有大量键在同一秒钟到期，那么Redis在检查这些键时，可能会瞬间需要删除非常多数据，这个删除操作是会占用主线程资源的，如果量太大，就会阻塞其他正常的读写命令，造成服务抖动，这就好比节假日高速公路出口，所有车都挤在同一时间出站，收费站再多的闸口也会排起长队。

为了避免这种“集中过期”引发的性能骤降，一个有效的办法是让键的过期时间尽量分散开，不要把所有用户会话的过期时间都设成一小时整，可以在基础时间上加上一个随机数，比如1小时加上0到300秒的随机偏移，这样，大量键的过期时间点就被打散了，避免了在同一时刻产生巨大的删除压力，这种做法在很多互联网公司的实践中被证明是有效的。

另一种情况是当内存使用达到上限,需要触发淘汰策略时，Redis提供了好几种淘汰算法，比如allkeys-lru（移除最近最少使用的键）、volatile-lru（只从设了过期时间的键中移除最近最少使用的）、allkeys-random（随机移除）等，选择哪种策略很重要，如果业务中有些数据是极其重要的，绝对不能丢，那么可能适合使用volatile-lru或volatile-ttl（优先移除剩余时间短的键），只淘汰那些有过期时间的、相对不那么关键的数据，为没有设置过期时间的核心数据留出空间，如果所有数据都可以被淘汰，那么allkeys-lru通常是比随机淘汰更明智的选择，因为它能尽量保住热点数据。

即使选对了淘汰策略,如果内存压力巨大，Redis为了腾出空间，可能还是会陷入频繁淘汰的循环，大量CPU时间花在决定“删谁”和“删除”本身上，这同样会影响性能，这时候，关键在于预防，而不是等内存满了再补救，一定要给Redis的内存使用设置一个安全的“水位线警报”，不要等到内存用到100%才行动，最好在达到总内存的80%或90%时就开始告警，这样运维人员或者自动化脚本就有充足的时间去排查：是业务量自然增长需要扩容？还是出现了异常的数据增长（比如代码BUG导致无限写入）？通过提前干预，可以避免数据库在极限压力下被迫进行激进的清理。

Redis自身也有一些配置参数可以用来微调清理行为,使其更“懒惰”一些，有一个配置项叫active-expire-effort，这个值默认是1，可以设置得更高，提高这个值会让Redis花费更多的CPU时间在后台主动、渐进式地查找并删除过期键，从而减少在主要工作周期内遇到大量过期键的可能性，这相当于把大扫除的任务化整为零，平时多干点零碎活，避免年底大扫除累垮自己，调高这个值会稍微多占用一些CPU，需要根据服务器的实际负载情况做一个平衡。

对于使用了Redis持久化功能（如RDB快照或AOF日志）的场景，内存清理还可能有额外的影响，当Redis执行RDB快照或重写AOF文件时，它需要遍历所有数据，如果此时内存中充满了已经过期但还没来得及被删除的键，Redis也会徒劳地检查它们，这会影响持久化的效率，通过上述更积极的后台过期键清理，也能间接改善这个问题。

还有一个容易被忽视的要点是监控,不能只盯着内存使用总量，更要关注一些关键指标，比如evicted_keys（被淘汰的键数量）和expired_keys（过期删除的键数量）的变化趋势，如果发现evicted_keys在持续、快速地增长，这就是一个明确的信号，表明当前的内存已经不足，淘汰策略正在频繁触发，性能风险很高，而expired_keys的突然飙升，则可能意味着刚刚发生了一波大规模的集中过期，通过监控这些指标，可以更早地发现潜在问题。

让Redis内存清理更平稳的核心思想是“化被动为主动，化集中为分散”，通过分散过期时间、选择合适的淘汰策略、设置预警水位线、调整后台清理参数以及加强监控，我们可以引导Redis以一种更温和、更持续的方式进行内存管理，从而避免因激进清理导致的性能抖动，确保应用程序能够享受到稳定、高速的Redis服务，这就像保持房间整洁，定期整理、随手归位远比等到无处下脚时再来一次大扫除要轻松和高效得多。