先用 redis-cli --latency-history 确认 Redis 本身是否真慢，若频繁＞20ms则内部处理变慢；否则问题在链路中间。再查慢日志、内存碎片、intrinsic-latency 等多维度交叉验证。
直接看 redis-cli --latency-history 定位是否真慢
别急着改配置或杀进程，先确认延迟是不是 Redis 本身的问题。用 redis-cli --latency-history 在 Redis 服务端本机跑——不是客户端，否则网络抖动会干扰判断。
- 如果输出里频繁出现 >20ms 的点（尤其在业务高峰时段），说明 Redis 内部处理确实变慢了
- 如果数值稳定在 0.3–0.8ms，但你的应用却报超时，那问题大概率在链路中间：DNS 解析慢、VIP 转发卡顿、代理层（如 Twemproxy/RedisShake）积压，甚至 Spring Boot 应用侧连接池耗尽
- 注意
--latency和--latency-history区别：后者每 15 秒打一个点，适合观察趋势；前者是实时流式采样，适合抓尖刺
查 SLOWLOG GET 前 10 条，重点盯 O(N) 命令和大 Key 操作
延迟飙升往往不是平均值上来的，而是某几个命令卡住主线程。打开慢日志，不是为了找“谁写了 bug”，而是看 Redis 正在被什么拖住。
- 执行
CONFIG SET slowlog-log-slower-than 5000（5ms 阈值），再SLOWLOG GET 10 - 如果看到
LRANGE user_list_2000 0 -1或HGETALL big_user_profile，基本可以锁定：这不是命令错，是数据规模超出结构承载力 - 更危险的是
KEYS *、SORT、ZUNIONSTORE这类真正O(N)命令——哪怕 N=10 万，也会让整个实例卡住几百毫秒 - 注意：
DEL和EXPIRE出现在慢日志里，大概率说明它正在删一个几 MB 的大 String 或几万字段的 Hash，不是命令慢，是数据太大
用 INFO memory 看碎片和淘汰策略是否已失效
内存问题常被误判为“CPU 不够”，其实 Redis 卡在内存分配上更隐蔽。重点关注三个字段：
-
used_memory接近maxmemory（比如 7.9GB / 8GB），且mem_fragmentation_ratio> 1.3 → 内存碎片高，malloc分配新块变慢 -
maxmemory_policy是noeviction？那一旦内存满，所有写入直接失败，而客户端重试逻辑可能造成请求堆积，放大延迟感知 -
evicted_keys为 0，但used_memory居高不下 → 说明没触发淘汰，可能是 key 都没设过期时间，或策略配成volatile-lru却全都没 TTL
别漏掉 redis-cli --intrinsic-latency 测基线，排除系统级干扰
这个命令测的是 Redis 自身事件循环的最坏响应能力，和业务命令无关。它能帮你快速区分：是 Redis 变慢了，还是它被系统拖累了。
- 在 Redis 服务器上执行
redis-cli --intrinsic-latency 100，跑满 100 秒 - 如果最大延迟突然从 3ms 跳到 30ms+，而
top显示 CPU 并不高 → 很可能是系统开了 swap、磁盘 I/O 堵塞（尤其 AOF rewrite 期间）、或内核启用了透明大页（THP） - 常见坑：
/sys/kernel/mm/transparent_hugepage/enabled是always状态时，Redis fork 子进程（如 bgsave/bgaof）会卡住上百毫秒，INFO stats里latest_fork_usec会暴增
真正麻烦的从来不是单个指标异常，而是多个信号交叉印证：慢日志里有大 Key、内存碎片率高、--intrinsic-latency 测出毛刺、监控显示 fork 耗时飙升——这时候得一起调，光改一个配置没用。
