Redis怎样在持久化与内存淘汰之间取得性能平衡
先说一个在运维中常遇到的棘手场景：Redis服务器在RDB快照期间，响应突然变慢，甚至出现卡顿。其核心原因可以归结为一句话：RDB快照期间内存淘汰变卡，是因为fork()触发写时复制且LRU/LFU策略需高频遍历计算，导致CPU负载飙升。 那么，如何缓解？业内常见的思路包括切换为random策略、临时调高maxmemory、启用lazyfree-eviction，以及优化RDB触发频率。下面，我们来拆解这背后的原理和具体操作。
为什么RDB快照期间内存淘汰会变卡
问题的根源在于两个高CPU消耗的操作在时间点上“撞车”了。当执行 bgsa ve 命令触发 fork() 时，操作系统需要为子进程复制父进程的页表，并启用写时复制（COW）机制。此时，如果主线程还在高频修改数据，就会不断触发内存页的物理拷贝，这本身就是个重负载操作。
雪上加霜的是，如果此时恰好启用了 allkeys-lru 或 volatile-lru 这类淘汰策略，事情就更复杂了。这些策略可不是随机挑一个key删除那么简单——每次需要释放内存时，Redis都必须遍历相应的dict或expires哈希表，并计算每个对象的 lru 时间差值，以找出“最近最少使用”的那个。这个遍历和计算过程，在内存压力大时是高频发生的。于是，写时复制带来的开销，与LRU/LFU策略的高频遍历计算开销叠加在一起，CPU负载很容易就冲上顶峰，导致服务卡顿。
在 RDB 执行中临时降低淘汰强度的实操方式
Redis本身并没有一个直接的“暂停淘汰”开关，但我们可以通过动态调整配置，在RDB期间临时给主线程“减负”。关键在于减少淘汰动作本身的计算开销和发生频率。
- 切换至轻量级淘汰策略：在通过脚本或监控系统感知到
bgsa ve开始时，立即执行CONFIG SET maxmemory-policy volatile-random或allkeys-random。随机淘汰策略完全避免了LRU/LFU所需的遍历和计算，能显著降低CPU消耗。 - 临时扩大内存“缓冲区”：如果业务能容忍短时间内的内存使用量上升，可以临时调高
maxmemory参数（例如增加10%）。这样做的目的是直接降低触发内存淘汰的阈值，减少淘汰检查的次数。 - 启用异步释放：配合设置
CONFIG SET lazyfree-lazy-eviction yes。这个选项能让淘汰key时的内存释放操作（unlink）异步执行，防止主线程被阻塞。
需要警惕的是，这些变更只对后续的淘汰行为生效，已经进入淘汰流程的key不会回退。好消息是，所有操作通过 CONFIG SET 即可运行时生效，无需重启实例。
RDB 频率与淘汰策略的协同配置建议
从根本上说，高频的 bgsa ve（例如每分钟一次）与计算密集型的LRU类策略本身就不太适配。更稳妥的架构设计，需要考虑两者的协同：
- 放宽RDB触发条件：将过于激进的
sa ve 60 10000调整为更宽松的sa ve 300 10等，直接减少fork操作的密度，从源头上降低冲突概率。 - 持久化路径分流：如果已经启用了AOF，可以考虑关闭RDB（
sa ve ""），将持久化压力完全转移到AOF的everysec同步机制上。AOF重写虽然也会fork，但其频率通常远低于不当配置的RDB。 - 选用TTL优先策略：对于大量设置了过期时间的key，使用
volatile-ttl策略是一个不错的折中。它只需要检查expires表中最近的过期时间，其计算开销比全局扫描LRU要轻量得多。
容易被忽略的底层细节
即使按照上述建议将策略切换为 randommaxmemory，Redis在每次执行写入命令前，都会调用 freeMemoryIfNeeded 函数来检查并尝试释放内存。这个检查过程本身就有固定的开销。
所以，真正治本的做法，不是纠结于用哪种淘汰策略“更省CPU”，而是让淘汰动作尽量少发生。这意味着需要做好容量规划：根据业务写入速率预留足够的Buffer，严格控制单个Key的大小，并通过监控将日常内存水平长期稳定在 maxmemory * 0.85 以下。如果内存水平持续在临界点徘徊，那么任何策略切换都只是扬汤止沸，无法解决根本的性能瓶颈。这才是实现持久化与内存淘汰之间高性能平衡的关键所在。
