Redis 排障要从延迟、命令、内存、客户端、持久化、复制和系统资源同时入手。只看 QPS 很容易漏掉真正的问题。

1. 学习定位

维度	内容
难度层级	排障专家
核心目标	先会用，再理解机制，最后能做工程取舍和故障分析
学习方法	带着业务场景看命令、SQL、数据结构、日志和运行时指标

2. 核心地图

Redis监控排障与性能优化
├─ INFO
├─ SLOWLOG
├─ LATENCY
├─ MONITOR
├─ commandstats
├─ memory
├─ replication
├─ blocked_clients
└─ 系统指标

3. 小章节深度讲解

下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。

3.1. INFO

是什么

INFO 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.2. SLOWLOG

是什么

SLOWLOG 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.3. LATENCY

是什么

LATENCY 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.4. MONITOR

是什么

MONITOR 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.5. commandstats

是什么

commandstats 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.6. memory

是什么

memory 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.7. replication

是什么

replication 属于 Redis 高可用或集群拓扑。它决定数据如何复制、故障时如何提升新主、客户端如何找到正确节点。

开发人员怎么用

开发人员要选择支持 Sentinel 或 Cluster 的客户端，并处理读旧数据、重定向、拓扑刷新和跨槽限制。

运维人员怎么看

运维人员要监控复制延迟、offset 差距、backlog 命中、Sentinel quorum、槽迁移和每个分片的内存/QPS/延迟。

常见风险

常见风险是只看集群总容量，忽略单槽热点、单 key 热点和客户端不支持重定向。

3.8. blocked_clients

是什么

blocked_clients 属于 Redis 事件循环和网络模型。Redis 能处理大量连接，是因为 IO 多路复用和短命令串行执行共同作用。

开发人员怎么用

开发人员要避免大响应、慢脚本、全量集合运算和无限阻塞读取。客户端超时、连接池和重试策略要与 Redis 延迟目标匹配。

运维人员怎么看

运维人员要关注 P99/P999 延迟、blocked_clients、客户端输入输出缓冲、网络吞吐和单核 CPU。平均延迟无法说明尖刺风险。

常见风险

常见风险是慢客户端消费响应太慢，输出缓冲不断增长，最终影响内存和事件循环。

3.9. 系统指标

是什么

系统指标 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。

开发人员怎么用

开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。

运维人员怎么看

运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。

常见风险

常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。

3.10. 本篇学习实验

建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。

开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。

4. 核心机制

• INFO 提供内存、客户端、命令、持久化、复制、CPU 等总体指标。
• SLOWLOG 记录执行耗时较长的命令，但不包含网络传输和客户端等待。
• Latency Monitor 能帮助发现 fork、AOF、expire、command 等延迟事件。
• 系统层面的 CPU、磁盘、网络和内存碎片也会影响 Redis 延迟。

5. 工程实践

• 基础监控包含 QPS、P99 延迟、内存、碎片率、慢命令、连接数、阻塞客户端、复制延迟。
• 故障时先判断是单命令慢、全局抖动、内存压力、网络问题还是下游回源。
• 使用 MONITOR 要非常谨慎，生产高峰可能放大负载。
• 优化优先级：改模型、拆大 key、避慢命令、隔离实例、再调参数。

6. 常见坑

• 只看平均延迟，忽略 P99 和尖刺。
• 慢日志为空就认为 Redis 没问题，实际可能是网络或客户端排队。
• MONITOR 长期开启导致额外压力。
• 优化只调 maxmemory，不处理大 key 和热点 key。

7. 专家视角

• Redis 排障要建立时间线：流量何时变化、命令何时变慢、内存何时上涨、复制何时延迟。
• 专家会用指标把应用、Redis 和系统层分开，避免互相甩锅。
• 性能优化的最高收益通常来自数据模型和访问模式，而不是参数微调。

8. Tips 快问快答

Q：SLOWLOG 记录网络耗时吗？

A：不记录，它主要记录命令在 Redis 内部执行耗时。

Q：MONITOR 能随便开吗？

A：不能。它会输出所有命令，生产高峰风险很高。

Q：Redis 优化先调参数吗？

A：通常先治理命令和 key 模型，再考虑参数。

9. 阶段小结

Redis监控排障与性能优化 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。