2. Redis故障诊断的底层知识体系

当Redis出现“变慢”“卡顿”“内存暴涨”“主从延迟”“集群频繁切换”等故障时，如果只停留在命令层面排查，很容易陷入“看现象猜原因”的循环。真正高效的诊断，需要把故障表现映射回Redis的底层运行机制：事件循环如何驱动命令处理、单线程模型如何决定阻塞边界、内存管理如何影响淘汰与碎片、持久化如何引入fork与磁盘压力、复制与集群通信如何造成延迟与状态抖动。理解这五条底层链路，才能把“症状”翻译成“机制”，再从机制定位到具体参数与操作。

事件循环与单线程模型：所有命令共享一条时间线

Redis的核心是一个基于epoll/kqueue的事件循环，它把文件事件（客户端连接、命令请求、回复写回）和时间事件（serverCron定时任务）统一编排。由于命令执行阶段是单线程的，任何一条耗时命令都会占用整条时间线，后续请求只能排队。因此，诊断时首先要区分“网络等待”和“命令执行阻塞”：前者表现为客户端超时但Redis自身CPU不高，后者表现为慢查询日志中出现大量耗时命令、latency监控出现尖刺。

可以用SLOWLOG GET 10查看最近慢查询，用LATENCY HISTORY event_name观察延迟事件。若发现KEYS *、HGETALL大对象、SORT无限制、FLUSHALL等命令频繁出现，基本可以判定是单线程被长命令阻塞。此时优化方向不是加CPU，而是拆分大key、改用SCAN、限制命令复杂度，或把重操作迁移到从节点/离线任务。

内存管理：淘汰、碎片与OOM的连锁反应

Redis内存由数据、缓冲区、复制积压、客户端输出缓冲、AOF缓冲等共同构成。当maxmemory触发时，淘汰策略（如allkeys-lru、volatile-ttl）开始工作；若没有可淘汰键，写入会返回OOM错误。诊断内存故障时，不能只看used_memory，还要看mem_fragmentation_ratio、used_memory_rss、mem_clients_normal、mem_replication_backlog等分项。

常见误区是“内存没满却写入失败”，这往往是因为淘汰策略为noeviction，或大量键没有TTL导致volatile-*策略无可淘汰对象。另一个典型是碎片率长期高于1.5，说明分配器与业务写入模式不匹配，可通过activedefrag yes开启主动碎片整理，或重启实例并配合MEMORY PURGE。诊断顺序建议：先看INFO memory确认总量与分项，再看INFO stats的evicted_keys与expired_keys，最后结合MEMORY USAGE key定位大key。

持久化机制：fork、磁盘与AOF重写的隐性代价

RDB通过fork子进程生成快照，AOF通过追加写日志并在重写时fork。fork本身会复制页表，若实例内存很大，fork耗时可能达到数百毫秒甚至秒级，期间主线程被阻塞。AOF的appendfsync策略决定落盘频率：always最安全但最慢，everysec折中，no依赖操作系统。若磁盘IO饱和，AOF写回会堆积，表现为aof_delayed_fsync上升、写入延迟增大。

诊断持久化故障时，重点观察INFO persistence中的rdb_last_bgsave_status、aof_last_write_status、aof_rewrite_in_progress、latest_fork_usec。若latest_fork_usec持续偏高，应考虑控制单实例内存、使用no-appendfsync-on-rewrite yes减少重写期间落盘竞争，或把持久化压力转移到从节点。注意：关闭持久化并不等于安全，主从切换时仍可能因数据未落盘而丢失。

复制与集群通信：延迟、脑裂与槽位迁移

主从复制依赖repl_backlog和PSYNC。若从节点断连时间超过积压缓冲区覆盖范围，会触发全量同步，导致主节点fork、网络带宽暴涨、从节点长时间不可用。诊断时看INFO replication的master_link_status、master_repl_offset与slave_repl_offset差值，差值持续扩大说明复制延迟。集群模式下，CLUSTER INFO的cluster_state、cluster_slots_assigned、cluster_known_nodes可判断槽位与节点健康；频繁的MOVED/ASK重定向、槽位迁移卡住、cluster-node-timeout过小导致误判下线，都是集群故障的常见来源。

下面这张图把五条底层链路与典型故障表现对应起来，便于在排查时快速定位“该看哪一层”。

把机制串成诊断路径

实际排障时，建议按“先看现象、再定机制、后查参数”的顺序推进。例如客户端报超时，先看SLOWLOG和LATENCY判断是否单线程阻塞；若阻塞不明显，再看INFO memory是否触发淘汰或碎片整理；若内存正常，再看INFO persistence是否处于fork或AOF重写；最后看INFO replication与CLUSTER INFO是否存在复制延迟或槽位异常。每一步都对应一个可观测指标，避免盲目重启或扩容。

需要强调的是，这五条链路并非孤立：fork 会占用内存和CPU，进而影响事件循环；复制全量同步会触发 fork 和网络风暴；集群槽位迁移会引入大量重定向和客户端重试。因此，诊断时要建立“机制联动”的视角，而不是单点归因。只有把底层机制与可观测指标对应起来，才能在复杂故障中快速缩小范围，做出正确的恢复决策。