核心目标理解主从复制的原理全量/增量同步、replicationid 与 offset与数据一致性边界理解哨兵如何实现监控、客观下线与自动故障转移部署一主一从一哨兵环境并完整演练一次主库宕机与旧主归队。前置知识完成 Part 5RDB——全量同步的载体与 Part 9主从切换丢锁的机制基础。验证环境Redis 8.10.0cygwin 移植版主库 6380、从库 6381、哨兵 26379 均为隔离实例故障注入在隔离环境进行。最后复核日期2026-08-07。0. 本篇问题场景单机 Redis 的三个单点机器宕机唯一的主库挂了服务全部不可用恢复靠重启持久化数据丢了主库磁盘损坏RDB/AOF 跟着没——持久化救不了机器没了读瓶颈QPS 高到单机 CPU 饱和加内存加机器都没用单线程。主从复制解决读扩展 数据冗余哨兵解决主库挂了自动切换。本篇先把复制讲透再演练一次完整的故障转移。1. 主从复制一主多从1.1 配置与角色# 从库配置一行即可redis-server--port6381--replicaof127.0.0.16380# 或运行时REPLICAOF127.0.0.16380部署后的角色实测INFO replication# 主库 6380 role:master connected_slaves:1 master_repl_offset:422 # 从库 6381 role:slave master_host:127.0.0.1 master_port:6380 master_link_status:up slave_repl_offset:422 ← 与主库 offset 一致 无延迟复制生效验证写主读从$ redis-cli -p 6380 SET product:1 机械键盘 OK $ redis-cli -p 6381 GET product:1 机械键盘1.2 同步机制全量 增量从库主库从库主库之后进入增量同步M 实时推送新命令PSYNC ? -1首次无历史BGSAVE 生成 RDB传输 RDB全量同步期间新写命令进 repl_backlog加载 RDB补发 backlog 中的增量命令两个关键概念概念作用replicationid主库的身份标识从库复制后继承repl_backlog主库的环形缓冲区存最近 N 字节写命令——断线重连时靠它做增量同步从库断线后重连如果断线期间产生的增量仍在 backlog 内 →部分同步只补发缺口如果断开太久、backlog 已覆盖不到 → 退化为全量同步重新传 RDB。全量同步的代价随数据量增长生产要监控repl_backlog_size是否够大。1.3 复制的一致性边界重要异步复制主库写命令先执行后传播从库有一定延迟——master_repl_offset与slave_repl_offset的差值就是延迟Part 12 会监控它从库可读但可能旧从库默认replica-read-only yes读从库拿到的是主库某时刻之前的数据过期键删除动作只由主库发起Part 6从库收到DEL才删——读从库可能在 TTL 之后短暂读到已过期键replica-serve-stale-data默认放行主库未开持久化 高危主库宕机重启后数据为空从库会同步到空生产必须主库开持久化或保证从库优先。2. 哨兵 Sentinel自动故障转移2.1 哨兵做什么哨兵是独立的 Redis 进程--sentinel对主库做四件事监控每 1 秒向主库/从库发 PING通知状态变化通知管理员/客户端自动故障转移主库不可用时选一个从库提升为新主配置中心客户端问哨兵当前主库是谁。2.2 下线判定与故障转移流程主观下线sdown单个哨兵 PING 超时down-after-milliseconds 客观下线odown达到 quorum 个哨兵都认为 sdown 选举 leader哨兵集群投票选一个执行故障转移的 leader 故障转移 1. 选一个从库优先级高、复制进度新 2. 对从库 REPLICAOF NO ONE 提升为主 3. 通知其他从库转向新主 4. 旧主恢复后自动降级为从库2.3 实测完整故障转移演练部署主 6380 从 6381 哨兵 26379quorum 1、down-after-milliseconds 3000。第一步——强杀主库$ taskkill /F /PID 19420 成功: 已终止 PID 为 19420 的进程。第二步——等待哨兵检测与切换约 8 秒$ redis-cli -p 26379 sentinel get-master-addr-by-name mymaster 127.0.0.1 6381 ← 哨兵已把新主指向 6381 $ redis-cli -p 6381 info replication role:master ← 原从库被提升为新主 connected_slaves:0第三步——新主可写$ redis-cli -p 6381 SET order:1001 paid OK第四步——旧主恢复归队$ redis-cli -p 6380 REPLICAOF 127.0.0.1 6381 OK $ redis-cli -p 6381 info replication role:master connected_slaves:1 ← 旧主已作为从库归队切换期间的代价从主库宕机到新主可写客户端有约检测时间 选举 提升的不可写窗口本实验约 5-8 秒期间写请求会失败应用需重试/排队。数据丢失窗口 主库宕机时刻尚未复制到从库的写入异步复制的天然延迟Part 5 的丢失窗口在复制场景同样存在。3. 脑裂故障转移的阴暗面网络分区下可能发生主库与哨兵/从库失联但主库自身还活着分区而非宕机。客户端写旧主分区中旧主仍接受写 哨兵判定旧主 o_down → 提升从库为新主 分区恢复 → 旧主归队成为从库 → 分区期间写入旧主的数据因从未复制给任何人而丢失防护配置redis.confmin-replicas-to-write 1 # 主库写请求至少要有 1 个从库在线 min-replicas-max-lag 10 # 从库延迟超过 10 秒视为不在线效果分区期间从库全部失联 → 旧主拒绝写入→ 数据不丢代价是写入短暂失败。这是保数据还是保可用的权衡min-replicas 倾向保数据。4. 客户端接入哨兵应用不直连主库而是问哨兵拿当前主库redis-pyfromredis.sentinelimportSentinel sentinelSentinel([(127.0.0.1,26379)],socket_timeout0.5)mastersentinel.master_for(mymaster,db0,decode_responsesTrue)slavesentinel.slave_for(mymaster,db0,decode_responsesTrue)master.set(k,v)# 读写走主slave.get(k)# 只读走从故障转移后客户端重新向哨兵询问即可拿到新主——应用代码无需感知切换。5. 版本与环境差异差异点说明REPLICAOF5.0 起替代SLAVEOF旧客户端注意复制协议7.x/8.x 均为 PSYNC2支持断线增量同步哨兵sentinel monitor配置在 7.x/8.x 一致quorum建议 ≥ 2生产至少 3 个哨兵cygwin 移植版fork/BGSAVE 行为与 Linux 有细微差异实验环境注明即可6. 测试与验收复制测试写主读从、master_link_status:up、offset 对齐故障转移测试隔离环境强杀主库 → 哨兵提升 → 新主可写 → 旧主归队脑裂防护测试断从库网络/停从库 → 验证min-replicas生效拒绝写。本篇验收清单能画出全量/增量同步的时序并说出repl_backlog的作用能解释replicationid/offset 与部分同步 vs 全量同步的判定能说出复制场景的三个一致性边界异步延迟、从库旧数据、过期键能区分 sdown/odown 与故障转移四步选主、提升、改向、归队能解释脑裂的丢数据场景与min-replicas-*防护的取舍部署过一主一从一哨兵并完成一次故障转移演练。7. 常见误区“从库会自动故障转移”——不会复制只提供冗余自动切换是哨兵的职责。“主库挂了数据一条不丢”——异步复制下未同步到从库的写入会丢丢失窗口 复制延迟§1.3。“主库没开持久化没关系有从库”——主库重启后变空从库会同步成空双输§1.3。“哨兵越多越好”——quorum 与哨兵数量要平衡单哨兵quorum 1能跑但无脑裂裁决能力生产 ≥ 3 哨兵。“脑裂只会丢数据写不进是 bug”——min-replicas的拒绝写正是防止丢数据的主动选择§3。8. 本篇小结复制解决数据有备份、读可扩展代价是异步延迟与一致性边界哨兵解决主库挂了怎么办代价是切换窗口与脑裂风险脑裂防护是保数据 vs 保可用的显式选择。但哨兵仍有上限单主库的写能力、单机内存的容量。数据量或写入吞吐超出单机时需要横向分片——下一篇 Part 11Redis Cluster 讲 16384 个哈希槽、MOVED/ASK 重定向与集群的扩容。9. 官方资料Replication 文档https://redis.io/docs/latest/operate/oss_and_stack/management/replication/Sentinel 文档https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/PSYNC2 复制协议https://redis.io/docs/latest/operate/oss_and_stack/management/replication/