性能诊断、监控与生产清单

学习目标

能够使用 Redis 诊断命令定位慢命令、大 Key、热 Key 和内存压力，并把实例指标、客户端指标、容量基线与变更回滚纳入生产操作。

核心知识点

本文按 Redis Open Source 8 稳定主版本的通用语义编写，官方文档核对日期为 2026-10-06。受管服务、ACL、采集器和小版本会影响可见字段与命令能力；执行前检查当前服务文档、用户权限和维护流程。

先区分应用端端到端延迟、网络往返和 Redis 命令执行时间。慢日志只记录超过阈值的命令执行耗时，不包括客户端网络和响应传输；实例没有慢日志不代表应用请求没有超时。Redis INFO、慢日志与系统 CPU、网络、磁盘指标必须对齐时间窗口，再与客户端连接池等待、超时、重试和序列化耗时关联。延迟排查、SLOWLOG。

诊断顺序建议从低风险、低频读取开始：先看客户端 SLO 与错误，再采样 INFO、SLOWLOG GET 10 和 LATENCY，按需对 SCAN 命中的有限候选执行 MEMORY USAGE ... SAMPLES 5。避免生产 KEYS、无限制 SLOWLOG GET -1、长时间 MONITOR，也不要把 MEMORY PURGE 当作高 RSS 的通用修复。运维命令可能消耗服务端 CPU、返回敏感 key/参数或影响延迟；生产诊断要通过最小 ACL、低频率、时间/样本上限和脱敏控制。

以下示例在连接到授权 Redis 8 节点的交互式 redis-cli 会话中逐节执行，不假定固定输出数值；如有 ACL，用 redis-cli --user lab_user --askpass，不要把密码放在命令参数、脚本或日志里。对于 Cluster，逐个主分片执行适用的观测，并用 CLUSTER SHARDS 确认目标节点；诊断结果按实例、时间和版本记录，不采集完整业务 key/value。

常用用法

SLOWLOG GET：限制慢命令样本并区分网络耗时

用于取得最近十条慢日志样本并与客户端超时的时间窗口对齐。

# 初始：已授权连接到 lab:diag:primary，事件时间范围和日志查看权限已确认。
# 边界：SLOWLOG GET 只读最近10条且需要相应权限；先脱敏参数和 key，禁止使用 -1 读取全部。
SLOWLOG GET 10
# 关键变化：取得有界的 Redis 命令执行样本，按时间戳对齐客户端和主机指标。
# 输出：0 到 10 条动态记录，包含命令执行耗时；实例与版本决定可见字段。

慢日志的耗时只覆盖 Redis 实际执行命令的阶段，不包含客户端网络、发送回复和应用处理。日志阈值由 slowlog-log-slower-than 控制，历史长度由 slowlog-max-len 限制；无记录可能表示阈值未命中或采集未启用，而不是证明没有慢请求。条目会包含命令参数，因此只能在授权环境内查看并对外分享脱敏后的摘要。SLOWLOG GET。

INFO：采样 CPU、客户端、网络和淘汰指标

用于读取一次实例状态快照，和同一时间窗的系统及客户端遥测对照。

# 初始：lab:diag:primary 的采样时间窗已记录，诊断账号仅有受控观测权限。
# 边界：INFO 仅由具备权限的授权连接低频读取并限制输出保留；字段随 Redis 版本和模块变化。
INFO
# 关键变化：记录 CPU、clients、stats、memory、persistence、replication 等区段的基线。
# 输出：对照 used_memory_rss、latest_fork_usec、evicted_keys 等实际字段；数值取决于节点负载。

重点对照命令统计和 instantaneous_ops_per_sec，主进程 CPU 与主机 CPU；latest_fork_usec、RDB/AOF child 与 copy-on-write 变化；evicted_keys、expired_keys、命中/未命中和 maxmemory_policy；连接数、阻塞客户端、拒绝连接、客户端缓冲与网络收发字节。INFO 字段是 maxmemory_policy，CONFIG 指令名是 maxmemory-policy。内存区段的 used_memory、used_memory_rss、allocator allocated/active/resident 和碎片指标需要与主机 RSS、swap、CPU、网卡吞吐及丢包一起看。具体字段名可能随版本变化，先核对 INFO 当前文档；slowlog_commands_* 汇总字段自 Redis 8.8 新增，旧版本应从慢日志和命令统计分别观察。INFO。

告警应和业务 SLO、主机容量以及实例用途绑定：同时监控 p95/p99 客户端延迟与服务端延迟、错误/超时/重试、客户端池等待、内存/RSS 余量、非缓存实例淘汰、复制偏移和链路、fork/COW 峰值、CPU、网络、磁盘和持久化状态。为每个主节点/分片建立峰值时段的容量基线，给客户端连接、复制/AOF 缓冲、allocator 碎片与 fork 期间的 COW 保留可验证余量；纯缓存与不可淘汰业务使用不同告警阈值，不采用脱离工作负载的统一百分比。告警要能关联变更和 runbook，避免按完整 key 或用户 ID 建高基数指标。Redis 延迟问题、INFO 指标说明。

LATENCY LATEST：检查阈值监控捕获的近期事件

用于在已启用适合本服务 SLO 的延迟阈值后查看最近记录的事件。

# 初始：已记录目标节点的 latency-monitor-threshold 配置和服务端 SLO。
# 边界：LATENCY LATEST 仅由具备权限的受控诊断连接低频查询；先判断监控阈值是否启用。
LATENCY LATEST
# 关键变化：对照 command 事件的 latest_ts 与 client_p99 采样，检查两条时间序列是否同步变化。
# 输出：可能为空；有记录时 event、timestamp、latest_ms、all_time_max_ms 由当前实例决定。

latency-monitor-threshold 以毫秒为单位，默认 0 表示禁用；应该按本服务可接受的 Redis 服务端延迟设定，而不是照搬某个固定阈值。LATENCY LATEST 返回各事件最近一条及其 all-time 最大值，不能替代应用侧分位数、完整请求历史或网络时延测量。若启用/修改阈值，先在受控环境衡量，再按变更流程设定并确认监控已产生预期事件。延迟监控框架、LATENCY LATEST。

LATENCY HISTORY：读取单类事件的有界历史

用于取得一个事件最近保留的时间戳与延迟点，以便和部署、负载、fork 或淘汰记录对齐。

# 初始：目标实例已启用延迟监控，且已从 LATENCY LATEST 确认 command 或 fork 事件存在。
# 边界：LATENCY HISTORY 只在具备权限的受控诊断连接读取一个事件，返回上限 160 点；禁止全量轮询。
LATENCY HISTORY command
# 关键变化：得到 command 事件的时间序列样本并对齐同一窗口的部署与主机数据。
# 输出：最多 160 对时间戳和毫秒延迟；是否有点由实际阈值命中决定。

每类事件的环形历史最多保留 160 个时间戳/延迟点，同一秒内多次命中会合并为该秒最大值。因此它是有界诊断采样，不是逐请求审计日志，也不能仅凭一条 command 事件断定根因。根据事件名分别调查命令执行、fork、过期或淘汰删除，并回到客户端网络与主机资源数据验证。LATENCY HISTORY。

LATENCY DOCTOR：把诊断建议与原始指标交叉验证

用于请求 Redis 对现有延迟采样生成一份人工可读的诊断建议。

# 初始：同一事件窗口的 LATENCY LATEST 与客户端 p99 延迟已保存，且诊断输出有脱敏接收人。
# 边界：LATENCY DOCTOR 仅由具备权限的诊断连接按需采样一次；不要把建议当自动修复。
LATENCY DOCTOR
# 关键变化：生成关于已采样事件的诊断文字，再与 client_p99 观测核对。
# 输出：人类可读的建议文本；与 `LATENCY LATEST` 的实际事件比对，无足够样本时不会形成根因结论。

LATENCY DOCTOR 返回人类可读的报告，可汇总事件间隔、离散程度并对部分事件给出建议；它不是含 event_type 等固定字段的结构化响应。报告没有应用请求上下文，也不替你验证修复效果。先把它作为线索，再核对慢日志、CPU、持久化 fork、淘汰和网络；不要因为建议提到某项配置就直接 CONFIG SET。LATENCY DOCTOR。

SCAN：用游标采样候选大 Key

用于按游标检查一页命名空间候选 key，并将扫描工作量限制在运维计划允许的范围内。

# 初始：目标节点和 lab:diag:large: 命名空间已确认，候选数量与本轮时间预算有上限。
SCAN 0 MATCH lab:diag:large:* COUNT 50
# 关键变化：SCAN cursor=0 返回下一 cursor 与当前页 key 名称，再由客户端去重并决定是否继续。
# 输出：COUNT 是工作量提示而非返回上限；同一 key 可能重复出现，非零游标须按预算继续。

SCAN 可将完整空间遍历拆成多次调用，但它不是快照：遍历中的新增/删除会影响可见结果，重复 key 由调用方去重，空页也不代表遍历结束。COUNT 只是每次工作的提示，服务端不保证返回数量上限；因此生产采样要采用有界策略，由客户端限制页数、总候选数和经过时间，在超出预算时保留游标后停止。Cluster 要逐个主分片检查，避免把单节点 SCAN 当成全局视图。不要以 KEYS 代替；大集合的同步完整枚举会阻塞其他请求。SCAN 游标与保证。

MEMORY USAGE：测量有限候选的大 Key

用于估算一个已由 SCAN 或应用采样选中的精确 key 在内存中的占用。

# 初始：lab:diag:large:doc-1 是当前隔离实例已知存在的聚合 key；生产时只替换为已审核的精确 key。
# 边界：MEMORY USAGE 只测一个明确 key 并用 SAMPLES 5 限制聚合采样；需权限且不循环扫描全库。
MEMORY USAGE lab:diag:large:doc-1 SAMPLES 5
# 关键变化：得到一个大 Key 的估算字节数，作为分桶采样而非全库精确排名。
# 输出：返回值随实际 key 类型、编码、子元素数量和版本而变。

对大 Key 诊断要先用 SCAN 发现候选，再从返回页挑少量 key，以 MEMORY USAGE ... SAMPLES 5 估算聚合类型的占用。SAMPLES 限制内部采样数量，但结果是估算值；大对象被反复抽中、对象编码变化和抽样偏差都需要记录。对候选按类型、大小和业务访问量分桶，先在低峰对少量 key 验证处理影响；不要对所有 key 执行昂贵估算或用遍历中的重复结果累加成伪精确容量。MEMORY USAGE、SCAN。

MEMORY STATS：区分数据集、allocator 与 RSS

用于在需要时读取一次内存拆分，解释 Redis 使用量与操作系统常驻集之间的差异。

# 初始：目标节点和观测时段已确认，INFO memory 基线及主机 RSS 采样可供对比。
# 边界：MEMORY STATS 只由授权连接低频读取一次；输出不含业务 key，但应受控保存。
MEMORY STATS
# 关键变化：取得 dataset、内部开销、复制/客户端缓冲及 allocator 统计。
# 输出：所有字节和比率随实例数据、allocator 与采样时间动态变化。

将 dataset.bytes 与 overhead.total 分开看，再对照 allocator.allocated、allocator.active、allocator.resident、allocator fragmentation、used_memory_rss 和主机 RSS。RSS 高于 Redis 已分配值可能来自分配器保留页、页碎片或历史峰值；反向关系也可能表示 swap 压力。不能仅凭 mem_fragmentation_ratio 判定泄漏，需观察时间序列、对象增长、allocator 页面与主机 swap。MEMORY STATS、INFO 内存字段。

MEMORY DOCTOR：获取内存问题提示

用于生成一次服务器内存诊断摘要，并把碎片建议与 MEMORY STATS 及主机指标交叉检查。

# 初始：已保存同一时段的 MEMORY STATS、INFO memory 和主机 RSS/可用内存样本。
# 边界：MEMORY DOCTOR 仅在具备权限的受控诊断连接按需读取一份；建议须结合碎片和数据增长验证。
MEMORY DOCTOR
# 关键变化：得到 Redis 对观测到的内存问题及可能处理方向的摘要。
# 输出：报告会按采样给出 used_memory 或 fragmentation 相关提示，不自动改变策略或释放数据。

DOCTOR 可以提示碎片或增长方向，但不能区分每个 key 的业务价值，也不是内存修复命令。先确认 used_memory、RSS、allocator 统计和数据集变化；只有指标支持时再比较主动碎片整理、数据结构拆分或容量扩展的成本。MEMORY DOCTOR。

MEMORY PURGE：受控评估 allocator 页回收

用于在已批准的隔离维护实验中观察 jemalloc 是否能归还空闲脏页。

# 初始：有隔离副本、已验证备份和 MEMORY STATS 基线，当前没有同步/持久化后台任务。
# 边界：MEMORY STATS 仅在授权连接低频采样；维护负责人已确认 allocator 与延迟预算。
MEMORY STATS
# 危险：MEMORY PURGE 只在隔离测试环境或已批准的维护窗口执行一次；操作可能较慢并升高延迟。
MEMORY PURGE
# 边界：MEMORY STATS 在受控诊断范围内仅再取一次核对，不能高频循环触发或用来替代容量处置。
MEMORY STATS
# 关键变化：allocator 尝试归还可回收的脏页，数据集本身不因此缩小。
# 输出：命令返回 OK；RSS 是否下降取决于 jemalloc、碎片与操作系统。

MEMORY PURGE 目前只在 jemalloc allocator 下尝试清理脏页；其他 allocator 上是无效果的 NOOP。它的耗时取决于已分配内存规模，可能较慢，不会删除 key、缩小 dataset 或修复过量增长。只有在对照 allocator、RSS 与客户端 p99 延迟后，才在隔离副本或获批低风险维护窗口做一次前后观测；不能将其当作容量扩展、数据清理或内存泄漏修复。MEMORY PURGE。

OBJECT FREQ：核实 LFU 候选并定位热 Key

用于对应用已经识别的少量热 Key 候选读取 LFU 的近似访问频率计数。

# 初始：诊断账号可查看 lab:diag:hot-candidate，测试实例预先以 LFU 淘汰策略启动。
OBJECT FREQ lab:diag:hot-candidate
# 关键变化：读取该 key 的对数访问频率计数，和应用按 key 分桶的请求样本对照。
# 输出：整数计数或 key 不存在时的空值；该值不是精确 QPS。

OBJECT FREQ 仅在 allkeys-lfu 或 volatile-lfu 等 LFU 淘汰策略下可用；计数是近似且会随衰减参数变化，不能解释为精确的时间窗口访问量。Redis INFO 的命令统计是按命令类型，不是按 key；热 Key 应主要由应用端低基数采样、key 哈希分桶、分片流量差和延迟分布识别，再对少量候选查询 FREQ。避免扫描全部 key 后逐个取频率，也不要把完整敏感 key 暴露在指标标签或诊断报告中。OBJECT FREQ、LFU 淘汰策略。

CONFIG GET：记录当前配置并分阶段变更

用于读取影响诊断与容量的当前配置快照，为变更前基线和验收记录提供证据。

# 初始：变更单已记录目标节点、SLO、容量基线、维护负责人和当前配置版本。
CONFIG GET maxmemory maxmemory-policy slowlog-log-slower-than slowlog-max-len latency-monitor-threshold
# 关键变化：把 active 配置和版本、时刻、实例 ID 一并记录，供分阶段验收或回滚比较。
# 输出：各参数当前值依环境而异；CONFIG GET 不等同于检查受管服务的全部源配置。

配置与拓扑变更的检查清单：

1. 先保存峰值负载基线：客户端 p95/p99、Redis 服务端延迟、超时/重试、命中与淘汰、CPU/网络/内存、replication offset 和持久化状态。
2. 写明容量假设与风险：目标 dataset、每分片热度、客户端连接上限、复制/AOF 缓冲、allocator 碎片、fork/COW 内存余量，以及数据能否重建。
3. 一次只改一类参数或拓扑步骤，使用配置源真相、受管服务流程或已批准的运行时配置入口，先在隔离环境和可回滚副本分阶段验证。
4. 定义观察窗口、验收指标、停止阈值、回滚动作和责任人；每阶段核对客户端重连/槽表、请求错误、延迟、淘汰、复制与主机资源。
5. 达到阈值立刻停止扩展并执行回滚验证，再检查业务读写和告警是否回到基线。回滚配置无法恢复已经被淘汰或故障期间丢失的数据，恢复仍依赖备份和应用修复流程。

CONFIG GET 只报告当前运行时看到的匹配项；某些托管服务不会开放 CONFIG，而文件、控制平面与运行时值也可能不一致。任何 CONFIG SET、拓扑重配或容量调整都应走相同的分阶段变更、业务验收和回滚流程，绝不为“试试看”在生产发出写配置命令。CONFIG GET。

MONITOR：短时间观察命令流的最后手段

用于在获得授权且普通指标无法定位时短暂观察一个隔离实例收到的命令流。

# 初始：已批准本次隔离实验的短时观测，目标为 lab:diag:primary，接收端已准备脱敏。
# 边界：MONITOR 仅在授权隔离测试环境运行最多5秒，随后 Ctrl-C 停止；禁止原样保存或转发敏感输出。
MONITOR
# 关键变化：capture_state 从 idle 变为 active_stream，达到5秒预算后 Ctrl-C 关闭会话。
# 输出：动态 timestamp/client/command/arguments 流；不要编写固定内容或保存原始参数。

MONITOR 是有危险边界的最后手段：redis-cli 会阻塞等待持续到达的命令流，服务端也要持续格式化并发送所有命令和参数；这些内容可能暴露 key、令牌、用户数据，并显著影响被测性能。仅作为短时应急线索，在隔离实例或获批低流量窗口采集最多 5 秒、完成脱敏并立即退出；不要放到常驻探针、性能基准或生产例行监控中。优先使用低频 INFO、有界 SLOWLOG 和应用遥测。Redis CLI MONITOR、Redis benchmark 中的监控影响。

易混点

• SLOWLOG 只覆盖 Redis 执行时间；LATENCY 监控需有合适阈值并保留有限事件历史；客户端 p99 还包含网络、连接池、序列化和调用方排队。
• used_memory、allocator 使用量、RSS 与容器/主机内存不是同一口径。峰值、碎片、复制缓冲和 fork 的 COW 可能让 RSS 在 key 删除后仍保持较高。
• 大 Key 是单个对象占用/操作成本高；热 Key 是访问集中。拆分大对象有重构和一致性成本，复制热 Key 有写入传播与缓存一致性成本，不能只看一个计数器决定。
• SCAN 的 COUNT 不是硬上限，重复与并发变化必须去重；MEMORY USAGE SAMPLES 是估算，不是全库精确排名。
• 生产告警阈值按 SLO、实例用途和峰值基线设定。容量评估要包含数据、连接、复制、AOF、allocator 和 fork 余量，并用演练验证扩容/回滚路径。

课后小问

1. 为什么客户端 p99 很高时，空的 SLOWLOG 仍可能是正常现象？
2. 对象大小和访问频率分别如何帮助定位大 Key 与热 Key？
3. 为什么 MEMORY PURGE 返回 OK 不代表 Redis dataset 下降或主机 RSS 必然下降？
4. 配置回滚能够恢复哪些状态，不能恢复哪些已经丢失或淘汰的数据？

本节小结

先把客户端延迟、Redis 执行、主机资源和网络按时间对齐，再用慢日志、LATENCY、INFO、SCAN 和有限内存测量逐步缩小范围。指标必须结合容量基线、告警、变更观察窗口与回滚验证；高风险诊断命令应在授权范围内限频、限样本、限时并脱敏。

快速回顾

慢日志区分执行耗时与网络；INFO 看 CPU、fork、客户端、网络、allocator 和 eviction；LATENCY 按阈值采样；SCAN + MEMORY USAGE 找少量大 Key；LFU/FREQ 与应用遥测辅助热 Key；变更前留容量基线，变更后按 SLO 验收并验证回滚。