学习自测与解析：Redis系列第三期与第四期核心知识点详解

本解析针对 Redis 系列第三期（持久化 RDB/AOF + 主从复制）和第四期（哨兵 + Cluster 集群 + 容器化）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固高可用与持久化相关原理和实战技能。

题目一：RDB 持久化的触发方式与 Copy-on-Write 原理

题目：Redis 的 RDB 持久化有哪几种触发方式？请说明 SAVE 和 BGSAVE 的区别，并解释 Copy-on-Write（写时复制）在 BGSAVE 过程中的作用。

考查知识点

RDB 触发方式（SAVE、BGSAVE、自动触发）------ 第三期 §2.1
Copy-on-Write 原理 ------ 第三期 §2.2

详细解答

RDB 触发方式：

方式	命令/配置	特点
手动同步	`SAVE`	阻塞主进程，执行期间无法处理任何请求，生产禁用
手动异步	`BGSAVE`	fork 子进程执行，不阻塞主进程（fork 瞬间有短暂停顿）
自动触发	`save 900 1` 等配置	满足条件时自动执行 `BGSAVE`

SAVE vs BGSAVE：

SAVE：由主进程直接写入 RDB 文件，期间阻塞所有客户端请求，适用于关机维护等场景。
BGSAVE：主进程 fork 子进程，由子进程完成写入，主进程继续处理请求，适用于生产环境。

Copy-on-Write 作用：

fork 时，子进程与父进程共享内存页（不复制整个内存）。
父进程继续处理写请求时，被修改的内存页才会被复制（写时拷贝）。
优势：节省内存和时间；代价：内存占用可能短暂增加（最多接近 2 倍）。

题目二：AOF 的三种写入策略及其适用场景

题目：Redis AOF 持久化的 appendfsync 参数有哪三种取值？请分别说明其行为、数据安全性及适用场景。

考查知识点

AOF 写入策略 ------ 第三期 §3.2
不同策略的权衡

详细解答

策略	行为	数据安全性	性能	适用场景
`always`	每个写命令立即调用 `fsync()` 同步到磁盘	最高（最多丢失一条命令）	最差	金融、支付等强一致性要求
`everysec`	每秒调用一次 `fsync()`（默认）	最多丢失 1 秒数据	较好	大多数生产环境（推荐）
`no`	由操作系统决定刷盘时机（通常 30 秒）	可能丢失大量数据（断电时）	最好	可接受丢失、追求极致性能

补充说明：

everysec 是性能与安全的平衡点，主线程每秒钟检查一次，如果上一秒的 fsync 尚未完成则跳过，保证不阻塞主线程。
修改策略：CONFIG SET appendfsync always（动态生效）。

题目三：RDB 与 AOF 的对比及混合持久化

题目：请从文件格式、恢复速度、数据完整性、备份适用性、性能开销五个维度对比 RDB 和 AOF。Redis 4.0 引入的混合持久化是什么？它解决了什么问题？

考查知识点

RDB vs AOF 对比 ------ 第三期 §4
混合持久化 ------ 第三期 §3.6

详细解答

RDB vs AOF 对比表：

维度	RDB	AOF
文件格式	二进制（紧凑）	文本（Redis 协议，可读）
恢复速度	快（直接加载）	慢（逐条重放命令）
数据完整性	分钟级丢失（最后一次快照后）	秒级丢失（默认 everysec）
备份适用性	适合（文件小，易传输）	不适合（文件大）
性能开销	低（fork 子进程，一次性写入）	中高（持续写盘）

混合持久化（Redis 4.0+）：

配置：aof-use-rdb-preamble yes
原理：AOF 重写时，先写入 RDB 格式的内容（二进制），再追加增量日志（文本）。
优势：结合了 RDB 恢复快 和 AOF 数据完整的优点，重启时先加载 RDB 部分，再重放增量命令，速度大幅提升。

启动恢复顺序 ：如果同时开启 AOF 和 RDB，Redis 优先加载 AOF（数据更完整）。

题目四：主从复制的全量同步与增量同步流程

题目：请简述 Redis 主从复制的全量同步和增量同步流程，并说明 runid、offset、repl-backlog-size 在其中的作用。

考查知识点

主从复制原理（全量/增量）------ 第三期 §5.2
关键组件（runid、offset、backlog）

详细解答

全量同步（首次连接或重连时 offset 不在 backlog 中）：

从库发送 PSYNC ? -1。
主库执行 BGSAVE 生成 RDB，同时将新写命令记录到复制积压缓冲区。
主库将 RDB 发送给从库，从库清空旧数据并加载。
主库将缓冲区中的增量命令发送给从库。

增量同步（正常运行或重连后 offset 仍在 backlog 中）：

从库发送 PSYNC <runid> <offset>。
主库检查 runid 是否匹配，offset 是否在 backlog 范围内。
若匹配且在范围内，主库将 backlog 中从 offset 开始的命令发送给从库。

关键组件：

runid：主库唯一标识，从库重连时发送旧 runid，用于判断是否仍连接同一主库。
offset：主从各自维护的复制偏移量，用于判断同步进度和数据差异。
repl-backlog-size ：复制积压缓冲区大小（环形），决定增量同步的最大可恢复范围。计算公式：backlog_size = 写入速率 × 预期断连时间。

题目五：一主两从搭建与故障手动切换

题目：在一主两从环境中，主库宕机后如何手动将从库提升为新主库，并让其他从库和原主库重新加入集群？请写出完整的命令序列。

考查知识点

主从搭建配置 ------ 第三期 §5.3
故障手动切换 ------ 第三期 §6.2

详细解答

环境：主库 192.168.108.10，从库 192.168.108.11、192.168.108.12。

故障切换步骤：

确认主库宕机：

bash

复制代码

redis-cli -h 192.168.108.10 -a master123 PING
# 无响应或超时

选择一个从库（如 192.168.108.11）提升为新主库：

bash
复制代码
```
redis-cli -h 192.168.108.11 -a master123 REPLICAOF NO ONE
```
将另一个从库（192.168.108.12）指向新主库：

bash
复制代码
```
redis-cli -h 192.168.108.12 -a master123 REPLICAOF 192.168.108.11 6379
```

恢复原主库并作为从库加入：

bash

复制代码

# 启动原主库
systemctl start redis
# 让它成为新主库的从库
redis-cli -h 192.168.108.10 -a master123 REPLICAOF 192.168.108.11 6379

验证复制状态：

bash

复制代码

redis-cli -h 192.168.108.11 -a master123 INFO replication
# 应看到 connected_slaves:2

题目六：哨兵的主观下线（SDOWN）与客观下线（ODOWN）

题目：在 Redis Sentinel 中，主观下线（SDOWN）和客观下线（ODOWN）分别是什么？故障转移过程中，为什么需要这两个状态？quorum 参数的作用是什么？

考查知识点

SDOWN 与 ODOWN 定义 ------ 第四期 §2.2
quorum 与故障转移流程 ------ 第四期 §2.3

详细解答

主观下线（SDOWN）：

单个 Sentinel 在规定时间（down-after-milliseconds）内未收到主库的有效 PONG 响应。
仅代表该 Sentinel 自己认为主库可能故障。

客观下线（ODOWN）：

超过 quorum 个 Sentinel 都认为主库 SDOWN。
代表集群多数节点确认主库故障，才会触发故障转移。

为什么需要两个状态：

防止网络抖动导致单个 Sentinel 误判。
通过多数派确认（quorum），避免不必要的故障转移。

quorum 的作用：

配置：sentinel monitor mymaster 192.168.108.10 6379 2
含义：至少需要 2 个 Sentinel 同意才标记 ODOWN。
通常设为 ceil(N/2)，例如 3 个哨兵时 quorum=2，允许 1 个哨兵故障仍能切换。

题目七：哨兵模式下的脑裂（Split-brain）预防

题目：什么是 Redis 哨兵模式下的脑裂？如何通过配置 min-replicas-to-write 和 min-replicas-max-lag 来预防？请说明配置原理。

考查知识点

脑裂问题与解决方案 ------ 第四期 §2.6
min-replicas-to-write 配置

详细解答

脑裂定义：网络分区导致旧主库与 Sentinel 失联，但旧主库仍继续接收写入。当网络恢复后，旧主库被降级为从库，期间写入的数据丢失。

预防配置（在主库上）：

conf

复制代码

min-replicas-to-write 1
min-replicas-max-lag 10

原理：

min-replicas-to-write 1：主库只有在至少 1 个从库在线且延迟 ≤ min-replicas-max-lag 时，才接受写请求。
当网络分区发生时，旧主库无法与从库通信，不满足条件，拒绝写入，从而避免脑裂期间产生脏数据。
配置需权衡：要求过高可能降低可用性（所有从库延迟超标时主库拒绝写入）。

题目八：Redis Cluster 的哈希槽与数据分布

题目：Redis Cluster 中共有多少个哈希槽？键是如何映射到槽的？什么是 Hash Tag？为什么要使用 Hash Tag？

考查知识点

哈希槽数量与映射 ------ 第四期 §3.2
Hash Tag 作用 ------ 第四期 §3.2

详细解答

槽数量 ：固定 16384 个（0 ~ 16383）。

键到槽的映射 ：slot = CRC16(key) & 16383（CRC16 返回 16 位，取低 14 位）。

Hash Tag：

定义：若 key 包含 {...}，只对花括号内的内容计算哈希。
示例：user:{1001}:name 和 user:{1001}:age 计算哈希时只对 1001 计算，落在同一槽。

为什么要使用 Hash Tag：

Redis Cluster 的多键操作（如 MSET、SUNION）要求所有 key 在同一槽。
Hash Tag 可以将相关 key 强制分配到同一槽，支持跨键操作。

题目九：Redis Cluster 的 MOVED 重定向与 ASK 重定向

题目：Redis Cluster 中 MOVED 和 ASK 重定向有什么区别？客户端应如何分别处理？

考查知识点

MOVED 与 ASK 重定向 ------ 第四期 §3.5
槽迁移与重定向

详细解答

重定向类型	触发场景	客户端处理方式
MOVED	key 对应的槽已永久迁移到另一个节点	更新本地槽映射缓存，向新节点重新发送命令
ASK	槽正在迁移中，key 可能在目标节点	先向目标节点发送 `ASKING`，再发送命令（不更新缓存）

MOVED 示例：

text

复制代码

(error) MOVED 5798 192.168.108.22:6379

客户端应更新缓存，后续请求直接发往 192.168.108.22。

ASK 示例：

text

复制代码

(error) ASK 5798 192.168.108.22:6379

客户端应先发送 ASKING 命令，再发送原命令（仅本次重定向，不更新缓存）。

题目十：Redis Cluster 扩缩容操作（添加节点与槽迁移）

题目：在 Redis Cluster 中，如何添加一个新主节点并为其分配槽位？请写出完整的命令流程。迁移槽位过程中，集群是否可正常服务？

考查知识点

集群扩缩容 ------ 第四期 §3.7
槽迁移与在线服务

详细解答

添加新主节点（192.168.108.27）并分配槽位：

启动新节点 （配置与其他节点相同，cluster-enabled yes）：

bash
复制代码
```
redis-server /usr/local/redis-6.2.14/redis.conf
```

将新节点加入集群：

bash

复制代码

redis-cli --cluster add-node 192.168.108.27:6379 192.168.108.21:6379 -a cluster123

迁移槽位到新节点（交互式）：

bash
复制代码
```
redis-cli --cluster reshard 192.168.108.21:6379 -a cluster123
```
输入：
- 要迁移的槽数量（如 1000）
- 目标节点 ID（新节点的 ID）
- 源节点 ID（all 表示从所有现有主节点平均抽取）

验证：

bash

复制代码

redis-cli -h 192.168.108.27 -a cluster123 CLUSTER NODES

迁移过程中集群是否可正常服务：

✅ 可以。Redis Cluster 的槽迁移是渐进式 的，迁移期间客户端可能遇到 ASK 重定向，但读写操作仍可正常进行。
迁移是以 key 为单位逐步完成的，不会一次性锁定大量数据。

附：知识点对应总表

题号	主要考查知识点（对应笔记章节）
1	第三期 §2.1 RDB 触发方式；§2.2 Copy-on-Write
2	第三期 §3.2 AOF 写入策略
3	第三期 §4 RDB vs AOF；§3.6 混合持久化
4	第三期 §5.2 主从复制原理（全量/增量）
5	第三期 §5.3 主从搭建；§6.2 故障手动切换
6	第四期 §2.2 SDOWN/ODOWN；§2.3 quorum
7	第四期 §2.6 脑裂预防与 min-replicas-to-write
8	第四期 §3.2 哈希槽与 Hash Tag
9	第四期 §3.5 MOVED vs ASK 重定向
10	第四期 §3.7 集群扩缩容与槽迁移

学习建议：对于答错的题目，请回看第三期或第四期对应章节，并动手在环境中执行相关命令。持久化和高可用是 Redis 生产环境的核心技能，建议在虚拟机或容器中完整搭建一次哨兵和集群环境，加深理解。