接口偶尔从几毫秒变成几百毫秒，应用监控把时间算在Redis上，但CPU和内存看起来并不高。Redis主要通过单线程事件循环执行命令，延迟可能来自慢命令，也可能来自fork、持久化、Swap、网络或宿主机调度。
先固定故障时间和延迟口径，再判断是哪一类阻塞。 只执行一次 PING 或只看平均值，很容易错过短暂尖峰。
从客户端和服务端同时确认延迟
先记录应用侧连接池等待、命令耗时和超时比例，再从与应用相同网络位置执行受控采样：
redis-cli -h 127.0.0.1 -p 6379 --latency
redis-cli -h 127.0.0.1 -p 6379 --latency-history本机快而远端慢，更接近网络、代理或连接池问题；本机也出现尖峰，才继续查看Redis内部事件和宿主机。生产环境不要长时间高频采样，避免监控本身制造额外连接。
平均延迟会掩盖尾部尖峰。至少对齐同一分钟内的P95/P99、超时和服务端事件，不能用一个平均数宣布Redis正常。
用SLOWLOG识别命令执行慢
查看慢日志配置与最近记录：
redis-cli CONFIG GET slowlog-log-slower-than
redis-cli CONFIG GET slowlog-max-len
redis-cli SLOWLOG LEN
redis-cli SLOWLOG GET 20SLOWLOG记录的是命令在Redis内部的执行时间，不包含客户端网络I/O。若应用感知很慢而SLOWLOG没有对应记录，问题可能在排队、网络、fork或宿主机暂停。
日志条目可能带有键名或参数。导出到工单前应脱敏，不要公开令牌、会话键和业务数据。 阈值太高会漏掉业务不可接受的命令，太低又可能产生大量记录，应按实际SLA设置。
找出高复杂度和大Key操作
慢日志中的 KEYS、大范围 LRANGE、SMEMBERS、HGETALL 或对大Key执行删除，都可能长期占用事件循环。不能只优化调用次数，还要看单次处理的数据规模。
在副本或低峰期使用 SCAN 分批定位键空间，结合应用模型判断大Key来源。不要在高峰期直接执行 KEYS * 或全量扫描。把阻塞命令改成增量操作，通常比单纯升级CPU更有效。
对于删除大对象，可评估 UNLINK 等异步释放方式，但仍需根据Redis版本、内存峰值和业务一致性验证，不能把所有 DEL 机械替换。
启用LATENCY监控捕捉内部事件
Redis延迟监控默认阈值可能为0，即关闭。先读取当前值，再按业务可接受延迟设置毫秒阈值：
redis-cli CONFIG GET latency-monitor-threshold
redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli LATENCY LATEST
redis-cli LATENCY DOCTOR阈值100毫秒只是示例。官方建议根据应用上限设定，只记录超过阈值的尖峰。配置在运行时修改后，如需跨重启保留，应结合配置管理确认持久化方式。
LATENCY LATEST 给出最近事件样本，LATENCY HISTORY 可查看时间序列，LATENCY DOCTOR 提供可读建议。这些结果是线索，不应脱离实际负载和主机指标自动执行所有建议。
检查持久化与fork影响
查看持久化状态：
redis-cli INFO persistence
redis-cli INFO stats
redis-cli INFO memory关注最近BGSAVE或AOF重写时间、fork耗时、失败状态和内存峰值。数据集较大、宿主机内存紧张或透明大页配置不合适时，fork可能造成延迟尖峰。
如果尖峰总与持久化任务同时出现，应先评估数据规模、写入速率、磁盘延迟和计划时间。不要为了消除延迟直接关闭持久化，这会改变故障恢复能力，需要独立评估数据风险。
检查Swap、CPU调度和虚拟化抖动
在同一时间窗口查看宿主机：
vmstat 1 10
pidstat -p $(pidof redis-server) 1 10
free -hSwap换入换出、CPU steal、磁盘等待和内存回收都可能让Redis事件循环暂停。云服务器CPU平均占用不高，也可能因宿主机调度出现短时延迟。
将 vmstat、Redis延迟事件和应用P99按时间对齐。只有多个信号同时出现，才足以把根因指向宿主机资源。 一次偶发的 st 或 wa 数值不能单独定案。
排除连接池和网络等待
应用统计的Redis耗时可能包含从连接池获取连接、DNS、TLS、代理和重试。检查池等待时间、活动连接、空闲连接及重试次数，确认命令真正送达服务端的时间。
跨区域连接Redis会把网络往返放大到每条命令。可通过批量、流水线或把计算移近数据降低往返，但必须评估错误处理和响应大小。不要把客户端超时无限调大，否则请求只会在队列里停留更久。
需要隔离网络与主机变量时，可以在 萤光云 上建立同区域对照环境，也可以用按小时计费的 LightNode 复现延迟采样。测试数据要脱敏，并限制压测并发，避免影响生产实例。
修复后覆盖真实峰值验收
优化慢命令、调整持久化或修复连接池后，重新覆盖原本容易出现尖峰的流量窗口。比较应用P95/P99、SLOWLOG数量、LATENCY事件和宿主机资源。
验收标准应包括尾延迟回落、超时率恢复、阻塞事件不再重复，并且持久化与数据安全要求仍然满足。 只让一次 PING 变快，不能证明业务链路已经恢复。
常见问题
SLOWLOG为空就说明Redis没有问题吗？
不是。SLOWLOG只统计命令内部执行时间，网络、排队、fork和宿主机暂停不会完整体现在其中。
latency-monitor-threshold应该设多少？
根据业务可接受的最大阻塞时间设置。先以SLA为依据，在观察期内调整，避免照搬固定阈值。
能否在生产环境运行MONITOR？
MONITOR会持续输出所有命令，开销和敏感信息风险都较高。常规排查优先使用SLOWLOG、LATENCY和聚合指标。
温馨提示
调整Redis配置前记录旧值，并确认修改是否需要写回配置文件。不要在生产高峰执行全量键扫描、MONITOR或未经限制的压测，这些动作本身就可能制造新的延迟。
