分布式系统不会只有一台服务器，为了防宕机、防磁盘损坏、保证数据不丢失，必须做多副本；随之而来就需要处理节点掉线、网络断连等故障，并且设计恢复逻辑让集群自愈。
一、数据复制（Data Replication）
1. 是什么
把同一份 Key-Value 数据，同步保存到多个不同节点机器上 ，每一份数据称为一个副本。 你的 Raft 集群 3 节点，写入一条 set k=1，同步到 2 台以上节点，就是典型的数据复制。
2. 三种主流复制模式
（1）同步复制（Raft 采用模式，强一致）
客户端写数据，Leader 必须等过半 / 全部副本复制完成，才回复写入成功。
- 优点：写完多副本，立刻保证数据安全，强一致性
- 缺点：等待网络应答，写入延迟略高
- 对应：Raft 日志复制、半数提交机制
（2）异步复制（Redis 主从、最终一致性）
Leader 写完自己本机，立刻返回客户端成功，后台慢慢异步同步给从节点。
- 优点：写入速度快、吞吐高
- 缺点：主节点刚写完就宕机，新数据还没同步，存在丢数据风险；短暂数据不一致
- 对应 BASE、AP 架构系统
（3）半同步复制
写完本机 + 至少一个副本收到日志，就返回成功，剩下副本后续异步补齐；折中方案，兼顾性能与数据安全性。
3. 复制的核心作用
- 容灾：一台机器硬盘损坏、宕机，其他副本还有完整数据，不会丢数据
- 容错：依托 NWR 多数派，实现集群过半节点存活就能正常对外服务
- 读写扩容：副本分担读请求压力
二、分布式常见故障类型（故障处理的前提）
- 节点宕机故障：服务器断电、进程崩溃、操作系统卡死
- 网络分区（脑裂）：节点之间网线 / 交换机故障，集群拆成两个互相不通的小团体
- 消息丢包、延迟、乱序：数据包在路上丢失、排队延迟、收发顺序错乱
- 数据磁盘损坏：节点本地日志持久化出错，数据本身损坏
三、故障处理（系统如何感知、应对故障）
以Raft 集群举例，整套故障处理逻辑：
- 故障检测 Leader 持续向 Follower 发心跳；Follower 超时收不到心跳，判定 Leader 故障。
- 自动应对策略
- Leader 故障：Follower 变身候选人发起新一轮选举，选出新 Leader，集群继续工作
- Follower 故障：Leader 不会等待故障节点 ACK，只要满足过半提交，写入照常进行；故障节点暂时脱离集群
- 网络分区：依靠递增 Term 任期号，旧 Leader 收到更大任期消息自动降级为 Follower，避免双主脑裂
- 约束兜底 依靠 Raft 安全性规则，故障期间不会出现已提交数据被覆盖、丢失的问题。
四、故障恢复（节点修好上线后，如何重新融入集群、补齐数据）
完整恢复流程（Raft 场景最典型）
- 节点重启上线 掉线、崩溃的机器修好后启动，读取本地持久化日志，初始化自身角色为 Follower。
- 日志差异比对 该节点主动和当前集群 Leader 通信，对比双方日志索引号，找出自己缺失的日志、冲突日志。
- 数据补齐修复
- 情况 1：本机日志落后很多 → Leader 逐条补发缺失日志，同步到本机
- 情况 2：本机存在错误、冲突日志 → 本机删除冲突日志，强制对齐 Leader 正确日志
- 重新加入集群 日志完全同步对齐后，该节点正式成为集群正常副本，参与后续日志复制、投票，集群副本数量恢复完整。
补充极端恢复：磁盘数据彻底损坏
节点本地全部数据清空，重新加入集群时，Leader 推送全量快照 + 增量日志，完成全量数据同步，完成恢复。
五、三者整体逻辑串联
- 数据复制：多节点冗余存数据，是容错的基础，分为同步、异步、半同步三种模式，Raft 使用同步复制保证强一致；
- 故障处理：集群通过心跳感知节点 / 网络故障，自动触发重新选举、隔离故障节点，保障集群业务不中断；
- 故障恢复：故障节点修复上线后，和主节点比对日志，补齐或回滚冲突数据，同步完整状态，重新回归集群，实现自愈。