Redis 持久化+高可用详解：RDB/AOF/混合/主从/哨兵/集群

前言

Redis 凭借其超高的吞吐能力和丰富的数据结构，已经成为后端开发中必不可少的中间件。无论是作为缓存 加速数据库访问，还是用作分布式锁 、消息队列，Redis 的身影无处不在。

然而，很多人对 Redis 的认识停留在"会用 API"层面，一旦遇到服务器宕机、数据丢失、主从切换失败 等生产问题，往往束手无策。根本原因在于：没有深入理解 Redis 的持久化机制与高可用架构。

本文将带你彻底吃透 Redis 的两大核心板块：

• 持久化（Persistence）：RDB 快照、AOF 日志、混合持久化 ------ 解决"数据丢了怎么办"
• 高可用（High Availability）：主从复制、哨兵 Sentinel、集群 Cluster ------ 解决"挂了我们怎么切"

无论你是准备面试，还是想提升生产排障能力，这篇文章都值得你花 20 分钟认真读完。每一小节都配有高频面试题，帮你做到"理解原理 + 应对面试"双丰收。

5. Redis 持久化（高频）

Redis 是 内存数据库 ，数据默认存储在内存中。内存虽然速度快，但有一个致命问题------ 断电即丢失。 如果 Redis 服务重启、服务器宕机或者机器断电，内存中的数据会全部消失。因此 Redis 引入了 持久化机制（Persistence）：

将内存中的数据保存到磁盘中，在 Redis 重启后恢复数据。

Redis 常见的持久化方案：

• RDB（Redis Database）
• AOF（Append Only File）
• 混合持久化（Redis 4.0+）

5.1 RDB

RDB（Redis Database）机制即 在某个时间点，把 Redis 内存中的数据生成一个快照，保存到磁盘。 因此 RDB 又叫 快照持久化（Snapshot） ， 最终生成文件dump.rdb。

原理

RDB 本质是某一时刻的数据全量备份 。

触发方式

1. 自动触发（save 规则） 更改 redis 配置文件，满足条件就执行 RDB。

# 900 秒内修改 1 次
save 900 1 

# 300 秒内修改 10 次
save 300 10 

# 60 秒内修改 10000 次
save 60 10000

2. 手动触发

• 执行 save 命令同步保存，但是此方法会阻塞 Redis，不推荐使用。
• 执行bgsave 后台异步保存，不会阻塞主进程，生产环境通常使用bgsave。

3. 主从复制触发

主节点全量同步时会自动生成 RDB 文件发送给从节点。

优缺点

优点：

1. 恢复速度快：因为是完整快照，可以恢复时可以直接读取dump.rdb文件，比 AOF 快。
2. 文件体积小：RDB 是二进制压缩文件，磁盘占用少。
3. 性能较高：持久化时由子进程完成，主线程影响较小。

缺点：

1. 可能丢数据：因为是定时快照。

如果：

12:00 保存一次
12:05 Redis 崩了

那么：

12:00 ~ 12:05

的数据全部丢失。

2. fork 开销大：数据量特别大时会消耗较多 CPU 和内存，可能出现短暂卡顿。

面试高频

Q1：RDB 为什么快？

因为它是二进制文件，恢复时直接加载整个数据。不像 AOF 需要逐条执行命令。

Q2：RDB 会阻塞 Redis 吗？

save 会阻塞，bgsave 不会。因为bgsave 会 fork 子进程异步执行。

Q3：RDB 最大问题是什么？

数据可能丢失 ，因为是间隔性快照。

---

5.2 AOF

AOF（Append Only File）：把每一次写命令记录到日志文件中。

例如：

执行命令：

set name tom
incr age

Redis 会记录：

SET name tom
INCR age

重启时重新执行这些命令恢复数据。

原理

三种刷盘策略

Redis 提供了三种不同的 AOF 配置策略，分别是always、everysec 和 no

1. appendfsync always
   即 每次写命令都刷盘，优点是几乎不会丢数据，但由于此策略会频繁IO，所以性能最差，适合对数据安全要求极高的场景。
2. appendfsync everysec
   即 每秒刷盘一次，安全性较高且性能好，最多丢失1秒数据，因此生产环境最常用。
3. appendfsync no
   表示 由操作系统决定什么时候刷盘，这种策略性能最好，但也最容易丢失数据，不推荐使用。

AOF 重写机制

如果 AOF 一直追加日志，文件会越来越大：

set a 1
set a 2
set a 3
set a 4

但实际上最终只需要：

set a 4

因此 Redis 提供：AOF Rewrite（重写机制），用来压缩 AOF 文件。

原始日志：

set num 1
incr num
incr num
incr num

重写后：

set num 4

文件显著缩小。

注意：AOF 重写不是读取旧文件修改，而是基于当前内存重新生成新的 AOF。

执行方式：

bgrewriteaof

底层同样由fork 子进程完成。

优缺点

优点：

1. 数据更安全：因为记录的是操作日志，丢失数据更少。

2. 可读性更强：AOF 是命令文本，可人工查看。

3. 支持更细粒度恢复：理论上恢复更完整。

缺点：

1. 文件更大：比 RDB 更占磁盘。

2. 恢复更慢：Redis 需要重新执行所有命令，所以慢。

3. 性能略低：持续写日志存在 IO 开销。

面试高频

Q1：为什么 AOF 更安全？

因为它记录每条写命令。 不是定时快照。

Q2：AOF 重写和 RDB 有什么关系？

两者都由fork 子进程后台执行 ，避免阻塞主线程。

---

5.3 混合持久化（Redis 4+）

Redis 4.0 引入了RDB + AOF 混合持久化 。这样做是为了同时兼顾恢复速度和数据安全。

原理

混合持久化：先用 RDB 保存全量数据，再用 AOF 保存增量命令。

恢复时：

先加载 RDB
↓
再执行 AOF 增量命令

流程：

RDB 快照
+
最近写命令(AOF)
=
完整恢复

这样既有RDB 快速恢复 ，又有 AOF 数据安全 。

不过这种方式虽然综合了前述两者的优点，但它的缺点也很明显：实现更复杂，维护成本更高。

---

6. Redis 高可用架构（高频）

Redis 虽然性能极高，但单机 Redis 存在明显问题：单点故障。一旦 Redis 宕机，缓存会失效，数据库压力暴涨，导致系统雪崩。因此生产环境通常不会只部署一个 Redis。

Redis 提供：

• 主从复制（Master-Slave）
• 哨兵模式（Sentinel）
• Redis Cluster 集群

其中：

主从复制是高可用基础。

6.1 主从复制

主从复制， 让一个 Redis 主节点的数据自动同步到多个从节点。 主节点负责写，从节点负责读。

为什么需要主从

主从复制主要解决以下问题：

1. 单机故障问题：
   如果只有一个 Redis，Redis 宕机后会导致整个系统服务不可用。有从节点后，即使主节点挂了，仍然可以切换从节点继续工作。这也是后面哨兵自动故障转移的基础。
2. 读压力过大：
   Redis 通常读多写少。如果所有请求都打到一个 Redis，主节点压力会很大。因此：主节点负责写、从节点负责读，这样实现读写分离，提高了并发能力。
3. 数据备份： 主节点数据会同步到多个从节点。相当于天然备份，降低数据丢失风险。

主从复制原理

配置从节点：

replicaof 192.168.1.10 6379

#旧版本
slaveof 192.168.1.10 6379

建立连接后：

同步过程分为：全量复制 和 增量复制

全量复制

全量复制：第一次同步时，把 Master 的全部数据同步给 Slave。 适用于新节点加入、第一次同步 和 断线时间太久。

增量复制

增量复制：只同步断线期间丢失的数据， 而不是重新同步全部数据。

面试高频

Q1：Redis 主从复制是同步还是异步？

默认异步复制。 Master写成功后立即返回，Slave后台同步。所以，主从可能短暂不一致，这是正常现象。

Q2：Redis 为什么需要增量复制？

因为 全量复制太重。 如果频繁断线，每次都全量同步，成本太高。因此Redis 使用PSYNC + offset + backlog buffer 实现断点续传。

Q3：主从复制能解决高可用吗？

不能完全解决。 因为当Master 挂掉时，Redis 不会自动切换主节点，仍然需要Sentinel（哨兵），实现自动故障转移。

---

6.2 哨兵模式（Sentinel）

前面提到 主从复制不能真正实现高可用。 原因是一旦 Master 宕机 ，从机 Slave 不会自动取代主机节点 ，这将会导致 Redis 服务不可写。因此 Redis 引入 Sentinel （哨兵模式），用于 自动监控 Redis，并在主节点故障时自动切换。

Sentinel 是什么

Sentinel（哨兵）是 Redis 官方提供的高可用解决方案，本质上是一个可以 独立运行的特殊 Redis 进程。 它不存储业务数据， 只负责监控 Redis 集群状态。

核心作用

Sentinel 主要有三大能力：监控 、自动故障转移 、通知

监控

Sentinel 会 定时向 Master 发送 PING 命令，持续检查 Master 和 Slave 是否正常。 如果超过一定时间没有响应，就会认为Redis 节点异常。

Redis 中分 主观下线 和 客观下线：

• 主观下线： 是指某个 sentinel 认为 Master 不可用。例如：sentinel1 向 Master 发送 PING 命令 30 秒没有收到响应，该 Sentinel 认为 Master Down，但不一定是真挂了，可能只是网络抖动。
• 客观下线： 是指多个 sentinel 共同认为 Master 挂了。例如 3 个sentinel 中有 2 个sentinel 认为 Master 挂了，达到 阈值quorum ，就判定客观下线，然后触发故障转移。这样做是为了避免误判。

自动故障转移

这是 Sentinel 最核心能力。 当Master 宕机，Sentinel 会 自动选一个 Slave 升级为新 Master， 无需人工干预。

通知

Redis 主节点变化时，Sentinel 会 通知客户端新的 Master 地址。

原来：

Master = 192.168.1.10

切换后：

Master = 192.168.1.20

客户端自动更新连接，保证服务尽快恢复。

故障转移流程

脑裂

什么是脑裂

脑裂（Split-Brain）是指：

集群中网络或节点故障导致部分 Sentinel 或节点无法互相通信，出现两个或多个节点都认为自己是 Master 的情况。脑裂出现时，客户端可能会读到旧数据或冲突数据，从而导致业务异常。

通俗理解：

• 集群被网络分成了两部分
• 两部分都各自选举 Master
• 客户端可能访问到不同的 Master，数据出现冲突

防止脑裂的方法

1. Sentinel 奇数部署
   • 至少 3 个 Sentinel，确保多数派原则
   • 多数派 Sentinel 判定 Master 是否下线
2. 合理配置 quorum
   • quorum = 判定 Master 下线需要的 Sentinel 数量
3. 网络隔离和监控
   • 保障集群节点网络稳定
   • 配合 Prometheus/ELK 监控网络状态
4. 使用 Redis Cluster
   • Cluster 的 Master-Replica + Gossip 协议更健壮
   • 自动感知节点分区，减少脑裂概率

缺点

虽然 Sentinel 很强，但也有明显问题：

• 无法解决容量问题：如果数据量太大，一个 Master 写压力有限。
• 存在短暂数据丢失 ：出现 Msater写成功，但是 Salve 还没有同步，Master 就挂了 的场景，最新数据可能会丢失。因为 Redis 默认异步复制。

面试高频

Q1： 为什么 Sentinel 要集群部署？

防止 Sentinel 自己挂掉。 生产环境通常至少 3 个 Sentinel，保证多数派机制，并且个数维持在奇数个。

Q2：Sentinel 和 Cluster 的区别？

Sentinel：解决高可用， 但单 Master，无法扩容。

Cluster：既解决高可用，又解决扩容问题。 因为 Cluster 支持多 Master 分片。

---

6.3 Redis Cluster（高频）

为什么需要 Cluster

Sentinel 虽然解决了高可用问题，但存在 单 Master 限制：

1. 内存容量有限：一个 Redis 节点内存终究有上限。
2. 写性能有限：所有写请求都打到一个 Master。
3. 无法水平扩容：数据量增长时无法横向扩展。

因此，Redis 引入 Redis Cluster（分布式集群） ，用于 数据分片 + 高可用。

---

Cluster 架构

Sentinel 是"单主高可用"，Cluster 是"多主分布式高可用"。

---

槽位机制（16384 Slots）

Redis Cluster 不直接按节点分数据，而是 将 所有键映射到 16384 个槽（slot）

示例：

0~5000       → Master1
5001~10000   → Master2
10001~16383  → Master3

写入操作：

set user:1 tom

Redis 内部流程：

key → CRC16(key) → %16384 → 得到 slot → 找对应 Master

实现 自动路由数据。

---

数据路由原理

客户端访问错误节点时，Redis 会返回：

MOVED 12182 192.168.1.10:6379

意思是：

key 对应的 slot 已迁移到新的节点

客户端会 自动重定向请求，保证访问正确节点。

---

面试高频

Q1：Sentinel 和 Cluster 区别？

特性	Sentinel	Cluster
Master数	单 Master	多 Master
功能	高可用	高可用 + 分片扩容
数据量	单节点内存上限	分片存储，支持横向扩容

Q2：Cluster 为什么是 16384 个槽？

分片数量够多，同时网络和存储开销较低，官方权衡后选 2¹⁴。

Q3：Cluster 如何实现高可用？

Master 挂掉 → 自动提升 Slave → 保证服务继续可用。

总结

一、知识点速查表

方案	核心机制	优点	缺点	适用场景
RDB	定时全量快照	恢复快、文件小	可能丢数据	缓存场景，可容忍分钟级丢失
AOF	追加写命令日志	数据更安全（everysec 最多丢1秒）	文件大、恢复慢	对数据一致性要求较高的场景
混合持久化	RDB 全量 + AOF 增量	恢复快 + 数据安全	实现复杂	生产环境推荐
主从复制	Master 写，Slave 读	读写分离、数据备份	Master 单点，不会自动切换	高可用基础
哨兵 Sentinel	监控 + 自动故障转移	解决 Master 自动切换	单 Master 容量瓶颈	中小规模，高可用要求
Redis Cluster	分片 + 多 Master	水平扩容 + 高可用	架构复杂，客户端要求高	海量数据、高写入场景

二、生产实践建议

1. 持久化选型

   • 开发/测试环境：RDB 默认即可
   • 对数据丢失敏感（如订单、库存）：AOF everysec + 混合持久化
   • 大容量缓存（可容忍分钟级丢失）：RDB + 主从

2. 高可用选型

   • 数据量 < 16GB、QPS < 10w：哨兵模式 + 读写分离（部署简单）
   • 数据量 > 50GB、写入量大：Redis Cluster（水平扩展）
   • 极端高可用要求：Cluster + 跨机房部署

3. 避免常见坑

   • 不要只用 save 命令做 RDB（会阻塞）
   • 不要关闭 AOF 重写（文件会无限增长）
   • 不要单节点部署 Sentinel（至少 3 个）
   • Cluster 槽位迁移时关注客户端 MOVED 重定向处理

三、推荐继续学习

如果你已经掌握了本文内容，可以继续深入：

• Redis 内存淘汰策略（LRU/LFU）与过期键删除机制
• Redis 事务与 Lua 脚本的原子性边界
• Redis 的慢查询分析与性能调优
• Redis 与数据库双写一致性问题（Cache Aside Pattern）