持久化与高可用

1. 这是什么

持久化用于把内存数据保存到磁盘，高可用用于在节点故障时尽量保持 Redis 服务能力。 这两部分决定了 Redis 是否能稳定支撑线上业务。

一句话理解：

• 持久化解决“掉电后数据还能不能回来”
• 高可用解决“节点挂了服务还能不能继续”

2. 为什么重要

如果只会把 Redis 当缓存用，而不了解持久化和高可用，就很难判断：

• 数据丢失风险
• 故障恢复策略
• 主从切换成本

生产环境里，Redis 不是只追求快，也要考虑稳。

3. 先建立直觉：主从复制不等于真正高可用

一个很容易误解的点是：

• 有主从复制 = 高可用

其实并不是。 复制只是说明：

• 数据在同步

但高可用还要额外解决：

• 故障检测
• 角色切换
• 客户端流量切换
• 复制延迟带来的业务影响

4. 核心内容

4.1 RDB

RDB 可以理解成：

• 某个时刻把内存快照落盘

优点：

• 恢复速度通常较快
• 文件体积通常更适合做备份

缺点：

• 两次快照之间的数据可能丢失

4.2 AOF

AOF 可以理解成：

• 按命令追加记录写操作日志

优点：

• 通常数据丢失窗口更小

缺点：

• 文件可能更大
• 恢复时要重放日志

4.3 混合持久化

混合持久化的思路可以先粗略理解为：

• 结合 RDB 的恢复效率
• 和 AOF 的数据完整性优势

学习阶段先建立这种工程折中意识即可。

4.4 主从复制

Redis 主从复制的核心目标是：

• 数据同步
• 读扩展
• 容灾基础

但它不直接等于：

• 自动故障切换

4.5 Sentinel

Sentinel 主要解决的是：

• 主节点故障检测
• 主从切换
• 配置感知

学习阶段最重要的理解是：

• Sentinel 关注的是高可用控制层
• 它和“单纯有从库”不是一回事

4.6 Cluster 基础认知

Redis Cluster 更适合解决：

• 数据分片
• 更大规模容量扩展

它不只是“多台 Redis”，而是：

• 带有槽位和分片语义的集群系统

5. 学习重点

这一章最重要的是掌握：

• RDB 和 AOF 的核心取舍
• 主从复制、Sentinel、Cluster 解决的是不同层次问题
• 有复制不等于真正高可用
• 恢复速度和数据丢失窗口是持久化设计的核心权衡

6. 常见问题

6.1 只关心性能，不关心丢数据风险

这会让系统表面很快，但可靠性不足。

6.2 把主从复制等同于高可用

复制和高可用不是同一件事。

6.3 不理解哨兵和集群的职责差异

一个偏高可用控制，一个偏分片扩展，不能混为一谈。

7. 动手验证

这一节我用当前已经跑起来的 Redis 容器做基础验证。

7.1 查看当前持久化配置

docker exec redis-lab redis-cli INFO persistence
docker exec redis-lab redis-cli CONFIG GET appendonly save

我已经实际看到过类似关键信息：

aof_enabled:0
rdb_last_bgsave_status:ok
save
3600 1 300 100 60 10000
appendonly
no

这些信息说明：

• 当前实例启用了基于 save 规则的 RDB 思路
• AOF 当前未开启

7.2 你应该观察什么

重点看：

• aof_enabled
• rdb_last_bgsave_status
• save 规则

这些字段能帮助你快速判断：

• 当前实例更偏哪种持久化模式

8. 练习建议

• 对比 RDB 和 AOF 的适用场景
• 画一张 Redis 高可用结构图
• 总结常见 Redis 部署模式差异
• 用自己的话解释“为什么复制不等于高可用”

9. 自测问题

• RDB 和 AOF 各有什么优缺点？
• Sentinel 主要解决什么问题？
• Redis Cluster 更适合解决什么类型需求？
• 为什么“有复制”不等于“高可用”？

10. 自测核对要点

• RDB 偏快照，AOF 偏日志
• 持久化设计核心在于恢复速度与数据丢失窗口的权衡
• 主从复制提供同步基础，不自动等于高可用
• Sentinel 和 Cluster 分别解决不同层面的系统问题