这是《Redis 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Redis 上线只是开始。本章覆盖日常运维、容量治理、备份恢复、版本升级、扩缩容、迁移与多活，让 Redis 长期稳定运行。
24.1 生命周期治理
每个 key 都应该有生命周期：
| 数据 | 生命周期 |
|---|---|
| 页面缓存 | 分钟级 TTL |
| 会话 | 小时级 TTL |
| token/验证码 | 分钟级或更短 |
| 排行榜 | 活动周期 |
| 延迟任务 | 执行后删除 |
| 配置缓存 | 版本失效 |
| 历史数据 | 迁出到 DB/对象存储 |
没有 TTL 的 key 必须有登记、容量预估和清理策略。
24.2 容量治理
容量水位
used_memory / maxmemory
数据增长趋势
淘汰数量
碎片率
复制缓冲
客户端输出缓冲
建议：
70% 进入容量规划
80% 告警
90% 严重，必须扩容或清理
key 治理
- 建立 key 前缀登记；
- 定期扫描大 key；
- 识别无 TTL 的常驻 key；
- 业务下线时同步清理 key；
- 破坏性结构变更走新版本 key。
24.3 日常巡检
PING
INFO memory
INFO stats
INFO persistence
INFO replication
SLOWLOG GET 10
CLIENT LIST
MEMORY DOCTOR
Cluster 额外：
CLUSTER INFO
CLUSTER NODES
建议节奏：
| 频率 | 动作 |
|---|---|
| 实时 | 核心指标告警 |
| 每日 | 检查容量趋势、慢查询 |
| 每周 | 大 key/hot key 扫描 |
| 每月 | 备份恢复演练、配置审计 |
| 每季度 | 故障切换演练、容量评审 |
24.4 备份与恢复
备份策略
对象: 从节点执行 BGSAVE，避免影响主节点
频率: 按数据重要性，日备/小时级
保留: 按恢复点目标 RPO
存储: 异机/对象存储/异地
验证: 定期恢复到临时实例
示例：
redis-cli BGSAVE
redis-cli LASTSAVE
cp /data/dump.rdb /backup/dump-$(date +%F-%H%M).rdb
恢复流程
1. 声明影响与目标 RTO
2. 准备新实例/临时实例
3. 放置 RDB/AOF
4. 启动并校验 DBSIZE、抽样 key
5. 修改客户端配置或切流量
6. 观察指标
7. 输出恢复报告
恢复演练必须真实执行，不能只确认备份文件存在。
24.5 版本升级
升级路径
1. 阅读 release notes 与升级指南
2. 测试环境完整演练
3. 确认客户端兼容性
4. 备份当前数据
5. 逐个从节点升级
6. 主从切换
7. 升级旧主节点
8. 观察稳定
注意
- 不建议跨太多大版本直接升级；
- 数据结构编码阈值可能变化；
- 持久化格式、AOF manifest 需兼容；
- Cluster 所有节点版本需协同；
- 升级前导出配置快照；
- 预留回滚窗口。
24.6 主从扩缩容
扩容从节点：
replicaof new-master-host 6379
masterauth password
注意：
- 避免多个从节点同时全量同步；
- 观察主节点复制缓冲；
- 大实例同步会占网络/磁盘；
- 新从节点稳定后再接入读流量。
缩容从节点：
确认 Sentinel 不依赖该节点
摘除读流量
执行 CLUSTER FORGET（Cluster 场景）
关闭实例
24.7 Cluster 扩缩容
添加主节点：
redis-cli --cluster add-node new:6379 old:6379
添加从节点：
redis-cli --cluster add-node new-replica:6379 old:6379 \
--cluster-slave --cluster-master-id <master-id>
迁移槽：
redis-cli --cluster reshard old:6379
redis-cli --cluster check old:6379
缩容：
redis-cli --cluster reshard old:6379 # 先迁走槽
redis-cli --cluster del-node old:6379 <node-id>
要点：
- 分批 reshard；
- 低峰执行；
- 大 key 拆分后再迁移；
- 期间监控 ASK 重定向和延迟；
- 迁移前后
CLUSTER CHECK。
24.8 数据迁移
常见方案
redis-cli --rdb导出/导入；- 主从复制迁移：目标实例 replicaof 源实例；
- SCAN + pipeline 双写/搬运；
- 云厂商迁移服务；
- 从上游数据库/事件流重建。
迁移流程
1. 建立目标集群并验证配置
2. 全量迁移
3. 增量追平
4. 双写或短暂只读
5. 校验数量与抽样值
6. 客户端灰度切流
7. 观察指标
8. 保留回滚窗口
校验
DBSIZE 对比（需稳定窗口）
key 前缀数量对比
抽样 value/hash
TTL 对比
业务指标对比
24.9 多活与容灾
同城双活
单元化路由：用户请求固定落在同城单元
缓存：本地单元为主
数据：DB 双向同步或单元封闭
Redis 缓存通常不跨机房强同步，而由业务数据源重建。
异地灾备
主站点 Redis -> 定期/实时迁移到备站点
RPO = 数据同步窗口
RTO = 切流与重建时间
必须明确：
允许丢多少缓存？
能否从 DB 重建？
切换时会不会击穿 DB？
是否需要预热？
灾备不是复制一份文件，还要有预热、限流和演练。
24.10 运维自动化
建议平台能力：
- 实例申请与配额；
- key 前缀登记；
- 配置模板与审计；
- 大 key 扫描；
- 容量趋势预测；
- 备份恢复演练；
- 哨兵/Cluster 健康巡检；
- 一键切换/扩容 runbook；
- 费用与僵尸数据治理。
治理比救火更能决定长期稳定性。
本章小结
- 所有 key 都要有生命周期，无 TTL key 必须登记；
- 容量水位 80% 告警、90% 必须处理；
- 备份必须在从节点执行并定期演练恢复；
- 升级采用滚动方式，从从节点开始；
- Cluster 扩容后必须 reshard，迁移要分批；
- 多活设计要先回答 RPO/RTO 与缓存重建策略。
思考题
- Redis 缓存异地多活时，为什么通常不双向同步所有 key？
- Cluster 添加节点后不 reshard 会发生什么？
- 设计一个每小时备份一次、RPO 小于 1 小时的恢复方案。