先用 redis-cli --intrinsic-latency 120 测 redis 内核基线延迟，max latency ≤100μs 正常，>500μs 表明主线程异常；再对齐 slowlog 与业务超时时间戳，调低 slowlog-log-slower-than 至 1000μs；盯住 instantaneous_ops_per_sec 与 evicted_keys 的负相关，结合 info memory 持续观察；警惕 del 大 key、集中过期、aof rewrite 等隐形阻塞源。
用 redis-cli --intrinsic-latency 确认是不是 Redis 自身变慢
别一上来就翻日志或改配置，先排除网络和客户端干扰。这个命令绕过网络栈，只测 Redis 内核处理空命令的延迟，结果直接反映主线程健康度。
- 在 Redis 服务器本机执行
redis-cli --intrinsic-latency 120，跑满 120 秒 - 重点看输出末尾的
Max latency so far：如果稳定在 100μs 以内，说明内核响应正常；超过 500μs 就得警惕 - 若这里也飙高（比如 >1ms），问题一定在 Redis 进程内部，不是网络抖动或代理拖慢
- 注意：这个值是基线，后续所有排查都要拿它作参照——运行时延迟超基线 2 倍，才算真变慢
对齐 slowlog 和业务超时时间戳
slowlog 是第一手线索，但容易误读。它记录的是命令执行耗时，不包含排队等待时间和网络传输时间，一个 GET 出现在 slowlog 里，未必是它自己慢，可能是前面有个 SORT 占着线程没释放。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
SLOWLOG GET 10，重点看第三字段（微秒级耗时）和第四字段（完整命令） - 把 slowlog 时间戳和业务报错时间对齐：比如某次超时发生在
14:23:05.123，而最近一条 slowlog 是14:23:05.120且耗时820000μs，大概率就是它堵住了后续所有请求 - 调低阈值：
CONFIG SET slowlog-log-slower-than 1000（即 1ms），默认 10ms 太宽松，毫秒级抖动根本捕不到 -
slowlog-max-len至少设为1000，否则高频慢操作会被覆盖，漏掉关键现场
盯住 instantaneous_ops_per_sec 和 evicted_keys 的负相关
当 instantaneous_ops_per_sec 突然下跌，大概率不是负载低了，而是主线程正被内存淘汰或过期 key 清理抢占。Redis 单线程模型下，这些后台动作和命令处理共享同一事件循环。
- 用脚本每 2 秒采一次
INFO memory，计算evicted_keys和expired_keys的每秒增量，>500/sec 是强信号 - 同时观察
used_memory_human是否长期 >95%maxmemory；若接近硬上限，淘汰已成常态 - 用
redis-cli --stat实时盯：若evicted列频繁跳变（如0→127→0→203），且cmd列同步萎缩（比如从8k → 2k），就是回收挤占命令处理的直接证据 - 不要依赖单次输出，要观察连续 5–10 秒的滚动变化；瞬时抖动无意义，持续性负相关才有诊断价值
检查大 key 删除、过期、AOF rewrite 这类“隐形定时炸弹”
这些操作看似“后台”执行，实则会间歇性抢占主线程 CPU 或触发内存拷贝，导致延迟尖峰。尤其在 big hash 场景下，rehash 可能拉长到几毫秒一次，客户端感知明显。
-
DEL bighash不是 O(1)，而是 O(N)，N 是哈希表 field 数量；应改用UNLINK，它异步释放内存 - 大量 key 集中过期时，Redis 会在
serverCron中批量清理，若过期 key 数量巨大，会卡住主线程 - AOF rewrite（
BGREWRITEAOF）期间，主线程仍需持续写入新命令到旧 AOF 文件，同时子进程做重写，内存与 I/O 压力双高 - 监控
INFO stats中的rehashing字段是否持续非零，配合mem_fragmentation_ratio > 1.5，基本可锁定 big hash 正在迁移
