网络分区策略Raft实现：保障分布式系统稳定的核心机制

在构建高可用的分布式ref="/tag/171/" style="color:#643D3D;font-weight:bold;">系统时，网络分区是一个无法回避的问题。比如你用的在线支付平台，突然某个机房断网，用户还能不能完成付款？这时候，像 Raft 这样的共识算法就派上用场了，它不仅能选出领导者，还能在网络异常时维持数据一致性。

Raft 是什么？简单说就是“投票选领导”

Raft 算法把分布式节点分成三种角色：领导者（Leader）、跟随者（Follower）和候选者（Candidate）。正常情况下，只有 Leader 接收客户端请求，然后把操作日志复制给其他节点。一旦网络出问题，比如两个机房之间断连，系统就得快速判断谁该继续服务，谁该暂停写入。

网络分区下 Raft 如何应对？

假设一个五节点集群，三个在机房 A，两个在机房 B。如果 A 和 B 之间的网络断了，B 中的两个节点收不到 Leader 的心跳，就会触发选举。它们会自增任期号，变成候选者并发起投票。

但问题来了：B 只有两个节点，凑不够多数（quorum），无法选出新 Leader。这意味着 B 节点会停止接受写请求，避免产生不一致的数据。而 A 中的三个节点仍然能组成多数派，继续提供服务。这就是 Raft 的“多数派原则”在网络分区中的体现——只允许能连通大多数节点的一侧继续运行。

分区恢复后如何同步数据？

当网络恢复，B 中的节点重新连上 A。它们会发现自己的日志落后于当前 Leader，于是主动从 Leader 那里拉取缺失的日志条目，追平状态。这个过程对客户端几乎是透明的，用户不会察觉刚才那段时间写入失败或延迟。

代码示例：简化版 Raft 心跳检测

下面是一个简化的心跳处理逻辑，用于判断是否进入选举：

// 伪代码：Follower 收到心跳
handleAppendEntries(request) {
  if (request.term >= currentTerm) {
    resetElectionTimeout();
    currentTerm = request.term;
    state = Follower;
  }
}

// 如果超时未收到心跳，启动选举
startElection() {
  currentTerm++;
  state = Candidate;
  votesReceived = 1; // 投自己一票
  sendRequestVoteToAll();
}

实际部署中的常见策略

在真实系统中，工程师会结合 Raft 做一些优化。比如跨区域部署时，把多数节点放在主数据中心，少数放在异地容灾中心。这样即使异地完全断网，主中心仍能工作。但如果主中心挂掉，异地只能读不能写，直到人工介入恢复。

还有一种做法是引入“租约机制”，让 Leader 持有短期写权限。即使网络抖动导致短暂失联，只要租约没过期，系统仍可继续处理请求，减少误判。

为什么 Raft 比 Paxos 更适合工程落地？

Paxos 虽然理论强大，但实现复杂，调试困难。Raft 把选举、日志复制、安全性拆解得更清晰，代码更容易写对。很多数据库如 etcd、TiDB、Consul 都选择了 Raft 作为底层共识协议，正是因为它在面对网络分区时行为可预测、易于监控和运维。

当你打开手机银行转账时，背后可能就有几十个节点正在通过 Raft 协商哪一条记录该被写入。这种看不见的协调，正是现代系统稳定运行的基石。