分布式共识算法
分布式共识算法解决多个节点如何就「同一个值」达成一致的问题。核心挑战：节点可能崩溃、网络可能延迟，但整个集群必须保持一致。
理论上的根本限制是 FLP 不可能定理（Fischer、Lynch、Paterson 于 1985 年证明）：在异步网络中只要有一个节点可能崩溃，就不存在算法能「一定」达成共识。工程实践的解决方案是绕开这个限制——放弃「一定」，改为「概率保证」（Paxos/Raft 通过多数派投票使共识失败的概率趋近于零）或「最终一致」（Gossip 通过信息扩散实现数据最终收敛）。
提示
Paxos、Raft、Gossip等分布式一致性算法原理
Paxos
Paxos 是 Leslie Lamport 提出的分布式共识算法，是后续多种共识算法的基础。
三个角色
| 角色 | 职责 |
|---|---|
| Proposer | 提出提案（编号 + 值） |
| Acceptor | 投票决定接受哪个提案 |
| Learner | 学习（记录）被批准的最终值 |
一个节点可同时担任多个角色。
两阶段流程
阶段一（Prepare）：Proposer 向 Acceptor 发送提案编号 N，要求承诺不接受编号小于 N 的提案。Acceptor 回复已承诺的最大编号和对应的值。
阶段二（Accept）：Proposer 收到多数承诺后，发送 Accept 请求（编号 N + 值 V）。Acceptor 收到后批准。
核心原则：多数派（n/2+1）批准即被选定。
Multi-Paxos
Basic Paxos 每轮需要两轮消息交互，延迟高。Multi-Paxos 引入稳定 Leader 概念，任期内跳过 Prepare 阶段直接 Accept，大幅减少消息数量。本质是选主 + 批量 Basic Paxos，etcd、ZooKeeper（ZAB）均基于此思路。
Raft
Raft 的设计目标是比 Paxos 更易于理解，将共识问题拆分为三个独立模块：Leader 选举、日志复制、安全性。
Leader 选举
节点状态：Follower → Candidate → Leader
触发条件：Follower 等待心跳超时（随机 150ms~300ms），超时后转为 Candidate 发起选举。随机超时避免分裂投票。获得多数节点投票者当选 Leader。
日志复制
客户端 → Leader（写日志）→ Follower（复制日志）→ 多数确认 → 提交 → 返回Raft 强制日志连续，不允许 commit 有空洞，比 Paxos 更易实现。
Raft vs Paxos
| 维度 | Paxos | Raft |
|---|---|---|
| 理解难度 | 高 | 低 |
| 领导模式 | 去中心化 | 强 Leader |
| 日志连续性 | 不保证 | 强制连续 |
| 实现代表 | ZooKeeper（ZAB） | etcd、TiKV、CockroachDB |
Gossip 协议
Gossip 模拟流行病传播，每个节点随机与其他节点交换信息，最终所有节点获得相同数据。
两种机制
| 机制 | 说明 | 适用场景 |
|---|---|---|
| 反熵 | 节点定期随机选一个节点，互换全部数据消除差异 | 新节点初始化、数据修复 |
| 谣言传播 | 拥有新数据的节点主动传播，收敛后停止 | 动态数据扩散 |
特点
| 特点 | 说明 |
|---|---|
| 最终一致 | 有限次传播后数据收敛 |
| 去中心化 | 无 Leader，节点对等 |
| 高可用 | 节点故障不影响整体传播 |
| 消息量大 | 有冗余，指数级扩散 |
应用场景：Cassandra 节点状态、Redis Cluster 集群状态、Nacos AP 模式的 Distro 协议。服务治理 中的注册中心正是这些共识算法的典型应用。
选型
Nacos 的 CP 模式使用 Raft，AP 模式使用 Distro（基于 Gossip）。
| 场景 | 推荐 | 原因 |
|---|---|---|
| 分布式配置/元数据 | Raft（etcd） | 强一致，Leader 保证顺序 |
| 集群成员关系 | Gossip | 最终一致即可，高可用优先 |
| 注册中心 AP | Gossip/Distro | 服务发现最终一致可接受 |
适用场景
| 场景 | 推荐算法 | 典型系统 |
|---|---|---|
| 分布式锁、分布式配置 | Raft | etcd、Nacos CP |
| 服务注册发现 | Gossip/Distro | Nacos AP、Consul |
| 分布式数据库 | Raft/Paxos | TiKV、CockroachDB |
| 集群状态同步 | Gossip | Cassandra、Redis Cluster |
FAQ
Q: Raft 和 Paxos 的核心区别是什么？ A: Paxos 去中心化，任何节点都可以发起提案，理解难度高；Raft 强 Leader 模式，所有写操作必须经过 Leader，将共识拆分为选举、日志复制、安全性三个独立模块，理解难度低。工程实践中 Raft 更常用（etcd、TiKV）。
Q: Gossip 协议为什么是最终一致而非强一致？ A: Gossip 通过随机选择节点交换信息来传播数据，不保证所有节点同时收到更新。传播需要多轮交互，每轮只覆盖部分节点，因此存在短暂的数据不一致窗口。但经过有限次传播后，所有节点最终会收敛到相同状态。
Q: 为什么 Nacos 同时使用 Raft 和 Distro？ A: 不同场景对一致性要求不同。配置管理需要强一致性（Raft），避免配置不一致导致业务异常；服务发现只需要最终一致性（Distro），高可用比强一致更重要。双模式让 Nacos 在两种场景下都能提供最优方案。