8.6.4 运维巡检与容量规划

运维巡检的目标是持续验证 Redis 服务可用性、稳定性与数据安全，建立标准化巡检清单与执行频率，做到“早发现、早预警、早处理”。巡检范围覆盖实例、主从/集群拓扑、系统资源、业务指标与安全配置，并输出可追踪的巡检报告以支撑容量规划与变更评估。

运维巡检与容量规划的关系可抽象为“采集—评估—决策—执行”的闭环：

巡检清单与关键命令（含解释）#

1) 实例存活与角色一致性

# 1) 连接实例并查看角色与复制状态
redis-cli -h 127.0.0.1 -p 6379 INFO replication
# 关键字段解释：
# role: master/slave
# connected_slaves: 从节点数量
# master_link_status: up/down
# master_last_io_seconds_ago: 主从延迟趋势参考

# 2) 哨兵健康（如使用 Sentinel）
redis-cli -p 26379 SENTINEL masters
# 预期：flags 不应包含 s_down/o_down

# 3) 集群槽位完整性（集群部署）
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER INFO
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER NODES | head -n 5
# 关键字段解释：
# cluster_state: ok
# cluster_slots_assigned: 16384

2) 性能与慢查询

# 实时指标概览
redis-cli -h 127.0.0.1 -p 6379 INFO stats
# 关键字段解释：
# instantaneous_ops_per_sec: QPS
# keyspace_hits/misses: 命中率
# total_connections_received: 历史连接

# 慢查询（毫秒）
redis-cli -h 127.0.0.1 -p 6379 SLOWLOG GET 10
# SLOWLOG 格式：id, timestamp, duration(微秒), command

# 设置慢查询阈值（举例：5ms）
redis-cli -h 127.0.0.1 -p 6379 CONFIG SET slowlog-log-slower-than 5000

3) 内存与碎片率、持久化状态

# 内存使用与碎片率
redis-cli -h 127.0.0.1 -p 6379 INFO memory | egrep "used_memory:|used_memory_rss:|mem_fragmentation_ratio:"
# used_memory: 实际数据内存
# used_memory_rss: 进程占用
# mem_fragmentation_ratio: >1.5 需关注

# RDB/AOF 持久化状态
redis-cli -h 127.0.0.1 -p 6379 INFO persistence | egrep "rdb_last_save_time|rdb_bgsave_in_progress|aof_enabled|aof_rewrite_in_progress|aof_last_bgrewrite_status"

4) 系统资源与网络健康

# CPU/负载/内存
uptime
free -m
# 磁盘IO
iostat -xz 1 3
# 网络丢包
sar -n DEV 1 3

5) 安全与配置一致性

# 检查 bind 与 protected-mode
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET bind
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET protected-mode

# 检查 ACL（Redis 6+）
redis-cli -h 127.0.0.1 -p 6379 ACL LIST
# 关注 default 用户是否被禁用、是否最小权限

标准化巡检脚本示例（可直接执行）#

目标：汇总健康信息并输出 JSON 报告，便于归档与容量分析。

# /opt/redis/ops/redis_audit.sh
#!/usr/bin/env bash
set -euo pipefail

HOST=${1:-127.0.0.1}
PORT=${2:-6379}
OUT=${3:-/var/log/redis_audit.json}
TS=$(date +"%F %T")

info_mem=$(redis-cli -h "$HOST" -p "$PORT" INFO memory)
info_rep=$(redis-cli -h "$HOST" -p "$PORT" INFO replication)
info_stat=$(redis-cli -h "$HOST" -p "$PORT" INFO stats)
info_pers=$(redis-cli -h "$HOST" -p "$PORT" INFO persistence)

used_memory=$(echo "$info_mem" | awk -F: '/used_memory:/{print $2}' | tr -d '\r')
mem_frag=$(echo "$info_mem" | awk -F: '/mem_fragmentation_ratio:/{print $2}' | tr -d '\r')
role=$(echo "$info_rep" | awk -F: '/role:/{print $2}' | tr -d '\r')
qps=$(echo "$info_stat" | awk -F: '/instantaneous_ops_per_sec:/{print $2}' | tr -d '\r')
rdb_last=$(echo "$info_pers" | awk -F: '/rdb_last_save_time:/{print $2}' | tr -d '\r')
aof_enabled=$(echo "$info_pers" | awk -F: '/aof_enabled:/{print $2}' | tr -d '\r')

cat > "$OUT" <<EOF
{
  "timestamp": "$TS",
  "host": "$HOST",
  "port": "$PORT",
  "role": "$role",
  "used_memory": "$used_memory",
  "mem_fragmentation_ratio": "$mem_frag",
  "qps": "$qps",
  "rdb_last_save_time": "$rdb_last",
  "aof_enabled": "$aof_enabled"
}
EOF

echo "OK: report saved to $OUT"

执行与预期：

bash /opt/redis/ops/redis_audit.sh 127.0.0.1 6379 /var/log/redis_audit.json
cat /var/log/redis_audit.json
# 预期输出包含 role、used_memory、qps 等字段

巡检常见问题与排错示例#

1) 主从延迟升高

redis-cli -h 127.0.0.1 -p 6379 INFO replication | egrep "master_link_status|master_last_io_seconds_ago|slave_repl_offset"
# 若 master_link_status=down 或 master_last_io_seconds_ago 持续增长：
# 排查网络：ping/iperf；排查磁盘 IO：iostat -xz；排查主节点慢命令：SLOWLOG GET

2) 内存碎片率高

redis-cli -h 127.0.0.1 -p 6379 INFO memory | egrep "used_memory:|used_memory_rss:|mem_fragmentation_ratio"
# 处理建议：评估大 key、热点 key，必要时重启/启用 jemalloc 参数或做节点扩容

3) 持久化失败

redis-cli -h 127.0.0.1 -p 6379 INFO persistence | egrep "rdb_last_bgsave_status|aof_last_bgrewrite_status|aof_bgrewrite_status"
# 若失败：检查磁盘空间 df -h，权限 ls -l /data/redis，IO 高 iostat -xz

容量规划方法与示例#

1) 内存需求估算（按数据量与 TTL）

估算公式：
预估内存 = 峰值数据量 × 安全系数(1.3~1.5) + 结构开销(10%~30%)

示例：
峰值数据量 100GB，安全系数 1.4，结构开销 20%
预估内存 = 100 × 1.4 × 1.2 = 168GB

2) QPS 与 CPU 评估（按命令类型与延迟）

# 采样实际 QPS 与延迟
redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep "instantaneous_ops_per_sec|total_commands_processed"
redis-cli -h 127.0.0.1 -p 6379 LATENCY DOCTOR
# 结合基线：单实例安全 QPS 与 P99 延迟阈值

3) 扩容触发条件（示例阈值）
- 内存使用率长期 > 70%
- 复制延迟持续上升（master_last_io_seconds_ago > 5s）
- P99 延迟超 2ms 或慢查询增长
- 热点 Key 导致单节点 QPS/CPU 高于 80%

扩容与变更执行示例（集群横向扩容）#

# 新增节点并加入集群
redis-cli --cluster add-node 10.0.0.8:7000 10.0.0.1:7000
# 重新分配槽位
redis-cli --cluster reshard 10.0.0.1:7000 --cluster-from all --cluster-to <new-node-id> --cluster-slots 2000 --cluster-yes
# 预期：cluster_state=ok，槽位分配完成

练习题#

1) 使用脚本采集三台 Redis 的巡检数据，输出到同一目录并生成汇总表（CSV）。
2) 人为制造一个慢查询（如大范围 LRANGE），观察 SLOWLOG GET 的变化，并调小阈值验证效果。
3) 在测试环境模拟内存水位达到 75%，给出扩容方案与回滚步骤，并记录关键命令。