Redis 持久化与高可用

Redis 系统讲解第三篇：数据怎么保住、服务怎么不倒。01 篇有 RDB/AOF 的对照结论表，这一篇讲机制细节——fork 与写时复制、AOF 重写、主从同步的全量/增量边界、哨兵的判定与选主、分片槽的迁移。

RDB：fork + 写时复制

bgsave 的完整流程：

主进程 fork 出子进程 → 子进程遍历内存生成 RDB 快照写入临时文件 → 完成后原子替换旧 RDB

关键机制是写时复制（COW）：fork 后父子共享同一份物理内存页；主进程继续处理写请求，只有被修改的页才会复制一份新页。所以：

• bgsave 期间 Redis 照常服务（子进程看到的是 fork 瞬间的数据快照）
• 写入量大的瞬间，内存占用可能瞬间翻倍——maxmemory 要留余量（实际用量的 2 倍左右是常见建议）
• fork 本身会阻塞主进程（复制页表，实例越大越久）——10GB 实例 fork 可能卡几百毫秒

自动触发：配置里的 save 900 1（900 秒内 1 次修改）等条件；shutdown 时若无 AOF 也会触发。

AOF：三种刷盘与重写

AOF 文件太大怎么办——重写（bgrewriteaof）：fork 子进程根据当前内存数据生成一份"最简命令集"（比如对同一个 key 的 100 次 INCR 重写成一条 SET），期间新写入进 AOF 重写缓冲区，重写完成后追加替换。效果类似"日志压实"，不读旧 AOF、直接以内存现状为准。

混合持久化（4.0+，aof-use-rdb-preamble yes）：重写时先写 RDB 格式的全量，再追加增量命令——恢复快（RDB 打底）+ 丢数据少（AOF 增量），生产默认开。

主从复制：全量与增量的分界

首次同步（全量）：
从库发 psync ? -1 → 主库 bgsave 生成 RDB → 传输 RDB → 从库载入
→ 期间新写命令缓存在 repl_backlog → RDB 加载完后补发缓冲区

断线重连（增量）：
从库带上自己已同步的偏移量 offset → 主库比对 repl_backlog：
  offset 还在缓冲区里 → 只发缺失部分（增量）
  已被环形覆盖 → 退回全量同步

repl_backlog_size 是关键调优项：缓冲区太小，网络一抖动就"被迫全量"——全量同步很重（fork + 传输 + 从库清空重载），生产要按写入速率和网络质量调大。

细节清单：主从都可用 INFO replication 看状态；从库默认只读；复制是异步的（主不等从，主挂了未同步的数据会丢——这就是 writeConcern 式取舍在 Redis 里的体现，用 WAIT 命令可要求确认）。

哨兵：三个任务与两次判定

哨兵集群（至少 3 个、奇数部署）干三件事：监控、选主、通知。

主观下线：单个哨兵 ping 不通主库 → 标记 sdown
客观下线：≥ quorum 个哨兵都认为 sdown → 升级 odown → 启动选举
选主：哨兵之间 Raft 式投票选出领头哨兵 → 它按规则挑新主（从库优先级/复制偏移量/runid）→ 通知客户端

我的记忆锚点：quorum 是"判定门槛"，不是"投票人数"——判定主挂了要 quorum 票，选领头哨兵要多数派，两套票分开理解。

客户端用法变化：连的是哨兵 asking "谁是主"，而不是写死主地址——Redis 客户端（redis-py 的 Sentinel 类、Java 的 Lettuce）都内置了这套发现逻辑。

分片集群：槽与迁移

• 16384 个槽，slot = CRC16(key) % 16384；节点负责一部分槽
• 客户端直连任意节点：key 不在该节点 → 返回 MOVED（客户端缓存槽位表，下次直连正确节点）
• 迁移期间的半成品 key：返回 ASK（本次先去目标节点问，不更新客户端缓存）——MOVED 和 ASK 的区别是书里高频考点
• 批量操作限制：mget 跨槽会报错——key 里带 hash tag（如 user:{100}:profile，花括号内才参与计算）可把相关 key 钉进同一槽
• 多 key 事务/Lua 同样受槽限制：同一 Lua 的所有 key 必须同槽

💡 高可用形态选择锚点：数据量小、读压力大 → 主从 + 哨兵就够；写也扛不住或数据到几十 GB → 分片集群。集群模式下的多 key 操作、事务、Lua 都受限，能用单机/主从解决的别急着上分片。

⬅️ 03-Redis 应用实战 🏠 00-数据库 ➡️ 05-Redis 底层原理与性能