Redis线上指标与集群运维#

一句话答案#

Redis 线上运维核心看 INFO 命令四类指标：内存（used_memory/碎片率）、性能（ops/latency/slowlog）、持久化（rdb/aof 状态）、复制（master_repl_offset 差值=延迟）；集群运维重点是主从切换、复制积压缓冲区和容量规划。

核心要点

一、INFO 命令关键指标

redis-cli INFO memory | INFO stats | INFO replication | INFO persistence

bash

类别	指标	含义	告警阈值
内存	used_memory	已用内存	>maxmemory 80%
内存	mem_fragmentation_ratio	碎片率=RSS/used	<1(swap!) 或 >1.5(碎片多)
内存	maxmemory_policy	淘汰策略	确认是 allkeys-lru 等合理策略
性能	instantaneous_ops_per_sec	当前 QPS	基线的 2 倍需关注
性能	latency (LATENCY LATEST)	命令延迟	P99 >5ms
性能	slowlog (SLOWLOG GET)	慢日志	>10ms 的命令
持久化	rdb_last_bgsave_status	最近 RDB 状态	err=磁盘/内存问题
持久化	aof_rewrite_in_progress	AOF 重写进行中	重写期间 fork 抖动
复制	master_repl_offset	主库写偏移量	主从差值=复制延迟
复制	repl_backlog_size	复制积压缓冲区	太小→全量复制
连接	connected_clients	当前连接数	>maxclients 80%
键	evicted_keys	被淘汰键数	>0 且持续增长=容量不足

二、内存碎片排查与治理

# 碎片率查看
INFO memory
# mem_fragmentation_ratio = used_memory_rss / used_memory

# 碎片率 > 1.5：内存碎片多，实际 RSS 远大于逻辑使用
# 碎片率 < 1.0：内存被 swap 到磁盘，性能急剧下降！

# 碎片治理
# 方案1：自动碎片整理（Redis 4.0+）
CONFIG SET activedefrag yes
CONFIG SET active-defrag-threshold-lower 10   # 碎片>10%开始整理

# 方案2：重启（清理碎片+重新加载）

# 碎片产生原因：频繁修改不同大小的value、大量删除键、jemalloc 分配策略

bash

三、复制积压缓冲区与主从切换

复制积压缓冲区（repl-backlog）：

作用：主库维护的环形缓冲区，记录最近的写命令
大小：默认 1MB（太小！建议生产设 64-256MB）
意义：从库短暂断线后，如果落后量在 backlog 内→部分同步；超出→全量同步（代价极大）

# 估算 backlog 大小
# backlog_size >= 主库写速率(MB/s) × 最大可接受断线时间(s) × 安全系数2
# 例：写速率 5MB/s × 60s 断线 × 2 = 600MB → 设 repl-backlog-size 600mb

bash

主从切换流程（哨兵模式）：

主库故障 → 哨兵检测(主观下线) → 多哨兵确认(客观下线)
  → 选举 leader 哨兵 → 选新主库(优先级/偏移量/ID)
  → 新主库 slaveof no one → 其他从库 slaveof 新主库
  → 通知客户端更新连接

plaintext

切换期间的数据一致性窗口：

异步复制 → 主库宕机前最后写的数据可能丢失
窗口大小 ≈ 主从延迟时间（通常毫秒级）
解决：min-slaves-to-write 1 + min-slaves-max-lag 10（至少1个从库延迟<10s才接受写）

四、容量规划

维度	估算方法
内存	单键大小 × 键数 × 1.5(碎片+元数据)
QPS	单实例 10-15 万 QPS（简单命令），复杂命令打折
连接数	应用实例数 × 连接池大小（通常 20-50/实例）
带宽	QPS × 平均 value 大小 × 2(读+写)
集群分片数	总内存 / 单实例内存上限(通常 10-20GB)

五、线上运维命令速查

场景	命令
看慢查询	`SLOWLOG GET 10`
实时监控命令	`MONITOR`（生产慎用！影响性能）
大 Key 扫描	`redis-cli --bigkeys` 或 `MEMORY USAGE key`
热 Key 发现	`redis-cli --hotkeys`（需开启 LFU 策略）
内存分析	`redis-cli --memkeys`
客户端列表	`CLIENT LIST`
实时延迟	`redis-cli --latency`

面试回答（2分钟版）

Redis 线上运维我主要通过 INFO 命令监控四类指标。内存方面看 used_memory 和碎片率，碎片率大于 1.5 说明碎片多需要开启 activedefrag，小于 1 说明发生了 swap 必须紧急处理。性能方面看 QPS 和 SLOWLOG，慢日志超过 10ms 的命令要排查是否有 O(n) 操作或大 Key。复制方面看主从偏移量差值，差值持续增大说明延迟在扩大。复制积压缓冲区默认 1MB 太小，生产上我建议设 64-256MB，否则从库短暂断线就要全量同步代价极大。主从切换通过哨兵自动完成，但异步复制意味着切换时有毫秒级数据丢失窗口，可以通过 min-slaves-to-write 限制主库只在有同步从库时才接受写入。容量规划方面单实例内存建议不超过 10-20GB 保证 fork 速度，QPS 上限约 10-15 万简单命令。

追问与易错

追问方向：

“碎片率小于1为什么危险？”→ 说明 RSS（操作系统实际分配内存）小于 Redis 逻辑使用内存，内存被 swap 到磁盘；Redis 单线程模型下任何磁盘 IO 都会阻塞所有请求，延迟飙升
“AOF rewrite 期间为什么会抖动？”→ AOF 重写需要 fork 子进程，fork 时要复制父进程的页表，内存越大页表越大复制耗时越长；fork 期间主线程阻塞，表现为请求延迟抖动
“全量同步为什么代价大？”→ 主库 fork 子进程生成 RDB 快照（内存翻倍风险）、通过网络传输完整 RDB 文件、从库加载 RDB 期间不可用；整个过程耗时长且资源消耗大
“怎么发现大 Key？”→ redis-cli —bigkeys 全局扫描各类型最大 key、MEMORY USAGE key 分析单个 key 实际内存占用、配合业务规范限制 value 大小和集合元素数量从源头预防

易错点：

❌ “repl-backlog 默认够用”——1MB 在高写入场景下几秒就满，必须调大
❌ “主从切换无数据丢失”——异步复制一定有窗口，只能缩小不能消除
❌ “碎片率高就重启”——先试 activedefrag，重启是最后手段
✅ 运维核心：INFO 四看（内存/性能/持久化/复制）+ SLOWLOG + bigkeys