1. 生产环境Redis性能问题诊断
Redis 在生产环境中的性能问题，很少以“Redis 变慢了”这种单一形态出现。它通常表现为 P99 延迟升高、QPS 突然下跌、连接数暴涨、内存持续增长、主从复制延迟扩大，甚至触发客户端超时熔断。要高效定位根因，第一步不是打开监控面板乱翻，而是先建立“瓶颈分类”的思维框架：把问题归入 CPU、内存、网络、磁盘/持久化、客户端与命令使用、集群拓扑这六类之一，再用对应的工具链逐层收敛。
一、常见性能瓶颈分类
Redis 是单线程处理命令的（Redis 6.0 后网络 I/O 可多线程，但命令执行仍是单线程），因此任何阻塞主线程的操作都会放大为全局延迟。按影响面从大到小，常见瓶颈可归为以下几类：
- 大 key 与热 key：单个 key 的 value 达到 MB 级，或某个 key 的 QPS 占整体 30% 以上。大 key 导致 DEL、HGETALL、LRANGE 等命令耗时飙升；热 key 则让单个分片 CPU 打满，其他分片空闲。
- 慢命令与阻塞操作：KEYS *、FLUSHALL、SORT、ZUNIONSTORE 大集合、未加 LIMIT 的 SCAN 循环，以及 Lua 脚本中执行复杂逻辑，都会长时间占用主线程。
- 内存压力与淘汰：used_memory 接近 maxmemory，触发频繁 eviction 或 swap，表现为延迟毛刺和 OOM 风险。
- 持久化与 fork 开销：RDB 快照或 AOF 重写触发 fork，copy-on-write 导致内存翻倍，fork 本身在数据量大时可达数百毫秒。
- 网络与连接问题：连接数过多、客户端未使用连接池、TIME_WAIT 堆积、带宽打满，都会让命令排队。
- 集群拓扑与热点分片：slot 分布不均、主从切换、跨机房复制延迟，导致部分节点负载远高于其他节点。
二、诊断工具链：从宏观到微观
Redis 自带了一套轻量但足够用的诊断工具，配合系统层工具即可覆盖大部分场景。核心工具链如下：
| 工具/命令 | 观察目标 | 典型用法与判读 |
|---|---|---|
| redis-cli --latency | 本机到实例的往返延迟 | 持续采样，若 avg 突然从 0.1ms 跳到 5ms 以上，说明主线程被阻塞或网络抖动 |
| SLOWLOG GET | 超过阈值的慢命令 | slowlog-log-slower-than 设为 10000（10ms），查看命令、耗时、客户端地址 |
| MONITOR | 实时命令流 | 仅短时使用，观察是否有异常命令或高频 key，生产环境慎用以免拖慢实例 |
| INFO all | 全局运行指标 | 重点看 instantaneous_ops_per_sec、used_memory、evicted_keys、blocked_clients、latest_fork_usec |
| redis-cli --bigkeys / --hotkeys | 大 key 与热 key | --bigkeys 扫描各类型最大 key；--hotkeys 需 maxmemory-policy 为 LFU 才有效 |
| redis-cli --intrinsic-latency | 系统固有延迟 | 排除 Redis 自身，判断是否宿主机或虚拟化层问题 |
系统层配合使用 top -Hp <pid> 看主线程 CPU、iostat -x 1 看磁盘 await、ss -s 看连接状态、perf top 看热点函数。这些工具与 Redis 自带命令形成互补：Redis 告诉你“哪里慢”，系统工具告诉你“为什么慢”。
三、真实故障案例的排查路径
下面以一个典型生产故障为例，展示从现象到根因的完整排查路径。某电商系统在晚高峰出现 Redis 响应超时，客户端报 Timeout waiting for idle object，P99 从 2ms 升至 80ms。
第一步：确认影响面。登录一台应用机执行 redis-cli -h redis-prod --latency，发现延迟曲线呈周期性尖峰，每 60 秒出现一次 200ms 左右的毛刺。这说明不是持续高负载，而是周期性阻塞。
第二步：查慢日志。执行 SLOWLOG GET 10，发现大量 BGSAVE 相关记录，以及 latest_fork_usec 达到 180000（180ms）。结合 INFO 中 rdb_changes_since_last_save 很大，判断是 RDB 快照触发 fork 导致主线程阻塞。
第三步：验证内存与持久化配置。查看 INFO memory，used_memory 为 12GB，maxmemory 为 16GB，未触发淘汰。但 save 60 10000 配置导致写密集时每分钟触发一次 BGSAVE，fork 时 copy-on-write 使内存峰值接近 20GB，宿主机开始 swap，进一步放大延迟。
第四步：定位根因并验证。根因是持久化策略与内存水位不匹配：数据量增长后，60 秒内写操作超过 1 万次，频繁触发 BGSAVE；同时宿主机内存不足导致 swap。调整方案：将 save 改为 save 300 10000，降低快照频率；扩容宿主机内存至 32GB；开启 activedefrag yes 减少碎片。调整后观察 24 小时，P99 回落至 3ms 以内，周期性毛刺消失。
四、根因定位方法总结
根因定位的核心是“分层排除 + 交叉验证”。建议按以下顺序推进：先看延迟是全局还是局部，再看是命令级还是系统级，最后看是配置问题还是容量问题。每一步都要有数据支撑，避免凭经验猜测。对于周期性毛刺，优先怀疑 fork、AOF 重写、定时任务；对于持续高延迟，优先怀疑大 key、热 key、连接数过多；对于突发下跌，优先怀疑主从切换、网络分区、内存淘汰。
最后强调一点：诊断工具的价值在于“用数据说话”。每次排查后，把现象、工具输出、根因、调整动作和验证结果记录成案例库，下次遇到相似毛刺时，可以直接比对 latest_fork_usec、evicted_keys、blocked_clients 这几个关键指标的变化趋势，把平均定位时间从小时级压缩到分钟级。