Redis峰值负载下的性能表现及CPU/内存过载时的处理逻辑

CPU占用达到逻辑核100%时的行为 #

默认配置下Redis核心命令执行是单线程模型，6.0及以上版本仅将网络IO读写拆到多线程，命令执行、过期淘汰、持久化触发等核心逻辑仍跑在单主线程上，CPU打满时的表现非常明确：

• 命令延迟陡增：所有待处理命令会在事件队列排队，原本微秒级的简单命令（GET/SET/INCR等）延迟会涨到毫秒甚至秒级，客户端大面积超时。此时查慢日志会看到大量无复杂逻辑的简单命令上榜，本质是排队等待执行，不是命令本身复杂度高。
• 定时任务滞后：Redis事件循环里的定时任务（过期key采样、主从复制心跳、RDB/AOF刷盘调度、集群节点心跳）会因为主线程被占满无法按时执行。最常见的连锁反应是：过期key清理不及时导致实际数据量临时上涨、主从/集群节点心跳超时触发故障切换、复制积压缓冲区溢出触发全量同步，进一步放大负载。
• 无主动限流逻辑：只要没触达maxclients连接数上限，Redis会持续接收新连接、新请求，积压队列会越堆越长，形成“排队占资源→更慢→更多排队”的雪崩循环，哪怕上游流量回落，也需要数秒到数分钟清空积压才能恢复正常延迟。
• 如果是6.0+版本开启了多线程IO，仅IO线程打满时表现为网卡软中断高、网络收发包队列堆积，核心执行线程负载尚低，但会出现连接建立失败、读写超时的现象；如果核心执行线程打满，表现和单线程版本完全一致。

内存超用时的行为 #

内存超用的表现和是否配置maxmemory参数直接相关：

• 未配置maxmemory时：Redis会无限制向系统申请内存，直到触达系统可用内存上限，触发Linux OOM Killer机制。默认规则下Redis作为内存占用最高的用户态进程，会被直接发送SIGKILL信号强制终止，未持久化的内存数据会全部丢失。如果当时刚好在执行RDB/AOF重写的fork操作，子进程的写时复制内存开销会让内存峰值翻倍，大幅提前OOM触发时间。
• 已配置maxmemory仍出现超用时，通常是三类场景：
  • 淘汰逻辑本身带来开销：内存触达maxmemory阈值后，每个写请求都会触发内存淘汰采样，如果配置的是allkeys-lru/volatile-lfu这类需要采样选淘汰key的策略，高写入压力下淘汰逻辑会额外占用大量CPU，反过来推高CPU负载、拉长请求延迟。
  • 内存碎片导致的实际占用超标：如果jemalloc内存碎片率（即info memory里的mem_fragmentation_ratio指标）长期高于1.5，你看到的业务数据内存（used_memory）没到阈值，但进程实际常驻内存（used_memory_rss）已经超过系统可用内存，同样会触发OOM。
  • 瞬时操作带来的内存尖刺：大key删除、多key聚合计算（比如SORT/SUNIONSTORE/大key批量写入）、fork后高写入压力触发大量写时复制内存页复制，都会导致瞬时内存峰值跳涨超过阈值，这种场景下要么OOM被杀，要么淘汰速度跟不上写入速度，出现请求阻塞。

线上运维和压测的共性结论：Redis本身没有内置过载保护机制，不会在CPU、内存超标时主动降载或者拒绝低优先级请求，所有过载保护都需要靠前置配置（合理的maxmemory和淘汰策略、连接数限制）、上游客户端熔断、代理层限流实现，否则过载状态下只会持续恶化，很难自恢复。

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