Appearance
Redis 持久化、高可用与集群
这篇笔记专门整理 Redis 在线上运行时最关键的稳定性主线：数据怎么落盘、故障后怎么恢复、节点怎么切换、容量怎么扩展。
Redis 的优势在于快，但只要进入生产环境，真正决定系统稳不稳的，往往是：持久化策略、复制链路、故障转移和集群扩展能力。
1. 🌟 持久化在解决什么问题
Redis 虽然以内存为核心，但这并不意味着数据就不需要恢复。
这里把“持久化”这个词本身说清楚：
持久化 指的是把原本只存在内存里的数据，按某种方式落到磁盘上。这样 Redis 进程退出、机器重启，或者节点故障后，才有机会把之前的数据重新恢复回来。
如果没有持久化，那么 Redis 更像一个“纯内存临时状态容器”：
- 进程一重启，内存里的数据就没了
- 机器一故障，节点上的状态就断了
- 新节点启动时，只能从空数据开始
持久化主要在解决这些问题：
- 进程重启后如何恢复数据
- 节点故障后如何减少数据丢失
- 是否需要更快的冷启动恢复
Redis 常见持久化方式有两种：
RDBAOF
它们不是谁“绝对更先进”，而是分别偏向不同目标。
2. 🌟 RDB（Redis Database）：快照思路
RDB 的核心思路是：在某些时刻把当前内存数据做成一份快照。
这里的“快照”可以理解成 把某一时刻 Redis 里的整体数据状态，像拍照片一样完整保存下来。
所以 RDB 保存的不是“每一次写命令发生了什么”，而是“某个时刻系统里最终长什么样”。
这也是为什么它恢复通常更快：
- Redis 启动时不需要一条条重放很多历史命令
- 只需要把这份快照直接加载回内存
- 更像是“直接把存档读回来”
2.1 优点
- 文件通常更紧凑
- 恢复速度通常更快
- 适合做备份和快速冷启动
2.2 代价
- 两次快照之间如果发生故障，可能丢失中间这段数据
- 快照本身也会带来额外开销
这里的“丢失中间这段数据”，意思是：
假设上一次快照是 10:00，下一次快照还没来得及生成，结果 10:05 机器宕机，那么 10:00 到 10:05 之间的新写入，就可能无法通过 RDB 找回来。
所以 RDB 更像是：偏恢复效率和快照备份的一种持久化方式。
3. 🌟 AOF（Append Only File）：命令追加思路
AOF 的核心思路是把写命令追加记录下来，后续通过重放命令恢复数据。
这里的 Append Only 可以直译成：只追加，不在原日志中间随意改写。
也就是说，每次有写操作时，Redis 会把这条“会修改数据的命令”按顺序记到文件末尾。后面如果要恢复数据，就从头到尾把这些命令重新执行一遍。
所以 AOF 保存的不是“某一刻的数据截图”，而是：数据是一步一步怎么变成现在这个样子的操作日志。
3.1 优点
- 数据恢复粒度通常更细
- 更容易降低数据丢失窗口
3.2 代价
- 文件可能更大
- 恢复过程可能更重
- 需要关注重写和磁盘压力
这里的“重写”也值得单独解释一下：
因为 AOF 会持续追加命令，如果一个 Key 被反复修改，文件里就会留下很多历史写入痕迹。为了避免日志无限膨胀，Redis 会在合适的时候把当前有效数据重新整理成一份更紧凑的新 AOF 文件，这就是 AOF rewrite。
所以 AOF 的成本不只是“写日志”，还包括：
- 持续追加带来的磁盘写压力
- 文件变大后的恢复成本
- 后台重写时的额外资源消耗
所以 AOF 更像是：偏数据完整性的一种持久化方案。
4. RDB 和 AOF 怎么理解它们之间的关系
把它们看成这样：
| 维度 | RDB | AOF |
|---|---|---|
| 核心思路 | 周期快照 | 追加写命令 |
| 恢复速度 | 通常更快 | 通常更重 |
| 数据完整性 | 两次快照间可能丢数据 | 通常更细粒度 |
| 文件特征 | 更紧凑 | 可能更大 |
很多线上环境会综合使用它们，不是为了“多配两个选项”，而是为了在恢复效率和数据安全之间取得平衡。
可以把它们先记成两种不同视角：
RDB关心的是“尽快拿到一份可恢复的数据存档”AOF关心的是“尽量把每一步写操作都保留下来”
前者更像备份快照，后者更像操作流水。
5. 🌟 主从复制解决的是什么
Redis 主从复制主要解决的是：
- 数据副本同步
- 读扩展
- 故障切换的基础条件
最基础的理解通常是：
- 主节点负责主要写入
- 从节点复制主节点数据
- 部分读流量可以分担到从节点
这里的“复制”本质上是：让多个 Redis 节点维持同一份数据的副本。
主节点上的写入不会自动凭空出现在从节点里，而是通过复制链路同步过去。所以主从架构的核心意义，不只是“多开几台 Redis”，而是：
- 主节点是主要写入入口
- 从节点保存相对接近主节点的数据副本
- 系统因此拥有读扩展和故障切换的基础
但要注意的是：
- 复制存在延迟
- 读从节点不等于一定读到最新数据
- 只配主从，不等于故障切换治理已经完整
这里的“复制延迟”要特别有画面感地理解：
主节点刚完成写入的那一瞬间，从节点可能还在同步路上。如果这时读请求被打到从节点，就可能看到旧值。所以主从复制能提升可用性和读能力，但天然会引入一定程度的“主从短暂不一致”。
6. 🌟 Sentinel 和 Cluster 不是一回事
这是 Redis 很容易被混成一类的两个主题。
7.1 Sentinel
Sentinel 更偏：
- 监控
- 故障发现
- 主从切换
- 高可用治理
它更像是“主从体系的高可用管理层”。
更具体一点说，Sentinel 本身不是拿来存业务数据的 Redis 节点，而是一组专门负责“观察和协调”的哨兵进程。
它主要做三件事：
- 盯住主从节点是否健康
- 判断主节点是否真的故障
- 在主节点不可用时，协助把某个从节点提升为新的主节点
7.2 Cluster
Cluster 更偏：
- 数据分片
- 横向扩展
- 集群路由
- 部分高可用能力
它更像是“进入分布式分片之后的集群形态”。
更直白地说，Cluster 不是简单的“一主多从”，而是：把整个 Key 空间拆给多台 Redis 机器共同承载。
所以它解决的是单机内存和单机吞吐迟早会碰到上限的问题。业务写入某个 Key 时，需要先根据路由规则知道这个 Key 该落到哪个分片节点上。
所以把这层分工记住：
Sentinel重点是高可用和故障转移Cluster重点是分片和扩展
7. Cluster 会带来什么新问题
只要进入 Cluster，系统关注点就不再只是“主挂了怎么办”，还要继续面对：
- 数据怎么分片
- 热点是不是集中到少数节点
- 某类 Key 是否造成明显倾斜
- 路由和扩容是否顺畅
把这些问题翻译成更具体的工程含义，就是：
- 某些多 Key 操作可能因为 Key 不在同一分片上而不能直接执行
- 热点业务如果刚好集中在同一槽位或同一节点，会出现局部过载
- 扩容时需要做数据迁移和重分布，过程本身也会带来波动
- 客户端必须理解或适配集群路由，不能再把整个 Redis 只当成一个单点地址
这意味着 Cluster 解决了容量和吞吐扩展问题，但也会把分布式复杂度一起带进系统。
所以 Cluster 不是“配置更高级”，而是系统规模继续增长后的架构选择。
8. 一份实用的持久化与高可用检查清单
可以优先检查这些问题：
- 数据是否需要持久化，容忍多大数据丢失窗口
RDB、AOF或组合方案是否贴合业务要求- 过期删除和内存淘汰策略是否分开设计
- 主从读写路径是否明确
- 是否只做了复制，却没有完整高可用治理
Sentinel和Cluster的使用边界是否清楚- 集群是否存在明显热点或分布不均
Redis 线上治理真正难的地方，不是把节点启动起来，而是能不能把恢复能力、高可用能力和扩展能力一起设计清楚。