Redis 平时响应在毫秒以内，生产环境突然延迟升高时，可能是慢命令、BigKey、持久化、内存回收、网络或宿主机抖动。重启虽然可能暂时恢复，但会丢失最有价值的现场证据。
一、确认影响和延迟位置
先区分是客户端到 Redis 的网络延迟，还是 Redis 服务端处理变慢：
redis-cli -h <host> -p <port> PING
redis-cli -h <host> -p <port> --latency
redis-cli -h <host> -p <port> --latency-history在 Redis 主机本地执行同样测试进行对比。远端慢、本地快，多半是网络、代理或连接池；本地也慢，则继续检查 Redis 和操作系统。
二、快速采集 Redis 状态
redis-cli INFO server
redis-cli INFO clients
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO persistence
redis-cli INFO replication
redis-cli INFO commandstats重点字段：
connected_clients、blocked_clients；used_memory、used_memory_rss、mem_fragmentation_ratio；instantaneous_ops_per_sec、rejected_connections；latest_fork_usec、RDB/AOF 状态；主从连接和复制积压；
各命令调用次数和累计耗时。
采集时不要高频循环执行 INFO，避免在故障中增加额外压力。
三、检查慢命令
redis-cli SLOWLOG LEN
redis-cli SLOWLOG GET 20
redis-cli CONFIG GET slowlog-log-slower-than
redis-cli CONFIG GET slowlog-max-len慢日志记录的是命令在 Redis 内部执行的时间，不包含网络传输和客户端排队。重点关注 KEYS、大范围 HGETALL、SMEMBERS、集合运算、Lua 脚本和一次删除超大 Key。
不要在生产大库直接执行 KEYS *。需要扫描时使用限制速率的 SCAN，并在低峰期进行。
四、识别 BigKey 与热点 Key
在副本或低峰期使用：
redis-cli --bigkeys
redis-cli --memkeys也可以使用 MEMORY USAGE <key> 检查已知 Key。--bigkeys 会扫描整个 keyspace，虽然使用 SCAN，仍可能增加网络和 CPU 压力。
热点 Key 可结合客户端埋点、代理指标或在可控窗口使用 redis-cli --hotkeys。该能力依赖 LFU 策略，使用前确认版本与配置。
五、检查阻塞客户端和长时间命令
redis-cli CLIENT LIST
redis-cli INFO clientsblocked_clients 增长不一定是故障，阻塞队列命令本身就会等待；但如果普通请求也变慢，应检查是否有 Lua、模块命令或大 Key 操作占用 Redis 主线程。
短时间使用 MONITOR 会产生大量输出并显著增加开销，生产高峰不要直接开启。优先使用 SLOWLOG、commandstats 和客户端指标。
六、检查持久化与 fork 抖动
redis-cli INFO persistence
redis-cli CONFIG GET save
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsyncRDB 保存或 AOF 重写需要 fork。内存很大、脏页多或宿主机内存紧张时，fork 会引发明显延迟。观察 latest_fork_usec、BGSAVE/BGREWRITEAOF 以及磁盘延迟。
vmstat 1 10
iostat -xz 1 10
pidstat -r -u -d -p $(pidof redis-server) 1 10
dmesg -T | grep -Ei 'oom|memory|transparent hugepage'同时检查 swap、Transparent Huge Pages、CPU steal 和磁盘 await。
七、检查连接池和网络
客户端连接池耗尽、连接频繁创建、DNS 抖动或代理转发也会表现为 Redis 慢。检查：
客户端连接池等待时间、活跃/空闲连接数；
total_connections_received增长速度；是否存在大量短连接和 TLS 握手；
云网络丢包、跨可用区延迟和代理节点负载；
客户端超时是否小于实际业务峰值。
八、应急处理步骤
停止或限流正在执行的高风险批处理和全量扫描。
对热点接口降级，避免请求继续堆积。
BigKey 删除优先使用
UNLINK，避免同步释放阻塞主线程。连接池耗尽时先限制新流量并修复泄漏，不要无限扩大连接数。
持久化导致抖动时评估磁盘和内存，不能在不了解数据安全要求时关闭 AOF/RDB。
主节点持续过载时，在确认一致性和容量后分担读流量、分片或迁移。
九、恢复后的验证
持续观察服务端延迟、P99、blocked clients、slowlog、CPU、RSS、fork 时间和客户端错误率。确认延迟回落后，再逐步恢复限流任务，避免一次性回放流量造成第二次冲击。
十、长期治理
为命令耗时、P99、连接数、内存、持久化和复制建立监控。
限制单 Key 大小，集合类数据拆分并设置合理过期策略。
禁止线上使用危险全量命令，脚本和 Lua 上线前评审复杂度。
容量规划同时考虑数据集、fork 峰值、复制缓冲和碎片。
客户端统一连接池、超时、重试退避和熔断策略。
定期做 BigKey、热点 Key 和慢命令巡检。
Redis 延迟排查要同时看命令、数据结构、持久化、操作系统和客户端，任何单一指标都不足以说明根因。