4、分布式协调服务：ZooKeeper核心原理、Paxos与Raft算法对比、Leader选举机制
说到分布式系统，有个绕不开的话题——协调服务。你想想看，一堆机器凑在一起干活，总得有个商量事情的地方吧？谁当老大？谁负责写数据？节点挂了怎么办？
ZooKeeper就是干这个的。我最早接触它是在2015年，当时做一套微服务架构，服务发现全靠它。说实话，刚开始觉得这东西挺玄乎，后来搞懂了它的核心思想，才发现设计得真巧妙。
4.1 ZooKeeper核心原理
ZooKeeper本质上是一个分布式协调系统。它提供了一组原语，让分布式应用可以安全地协调工作。
它的核心模型很简单：
- 树形命名空间：类似文件系统的目录结构，每个节点叫ZNode
- ZNode类型：持久节点、临时节点、顺序节点
- Watcher机制：客户端可以监听节点变化，一旦触发就收到通知
关键点：ZooKeeper保证的是CP（一致性+分区容错性），不是AP。这意味着在发生网络分区时，它优先保证数据一致，可能会牺牲可用性。
我记得有个同事问过我：「ZooKeeper到底存什么数据？」嗯，它不存业务数据。它存的是配置信息、集群元数据、锁状态这类轻量级数据。每个ZNode默认只能存1MB数据，别拿它当数据库用。
4.1.1 ZNode的生命周期
ZNode有三种类型，每种用途不同：
| 类型 | 特点 | 典型用途 |
|---|---|---|
| 持久节点 | 创建后一直存在，直到手动删除 | 存储配置信息 |
| 临时节点 | 客户端会话结束时自动删除 | 服务注册、心跳检测 |
| 顺序节点 | 名称自动加序号，保证唯一性 | 分布式锁、队列 |
我的经验：临时节点特别适合做服务健康检查。我曾经用临时节点做了一套服务注册中心，节点挂了，ZooKeeper自动清理，比手动维护心跳表省心多了。
4.2 Paxos与Raft算法对比
说到分布式一致性算法，Paxos和Raft是绕不开的两个名字。很多人觉得Paxos难懂，Raft相对好理解。我个人也觉得Raft的设计更「工程化」一些。
4.2.1 Paxos算法
Paxos是Leslie Lamport在1990年提出的。它的核心思想是「两阶段提交」的变体：
- Prepare阶段：Proposer向Acceptors发送提案编号，获取承诺
- Accept阶段：Proposer发送提案值，Acceptors投票决定是否接受
Paxos保证了安全性（Safety），但不保证活性（Liveness）。说白了，它保证不会出现两个不同的值被同时选定，但可能永远选不出一个值。
注意：Paxos的工程实现非常复杂。我见过不少团队尝试自己实现Paxos，最后都放弃了。不是算法本身有问题，而是边界情况太多，容易踩坑。
4.2.2 Raft算法
Raft是2013年提出的，设计目标就是「可理解性」。它把一致性协议拆成了三个子问题：
- Leader选举：选出一个Leader，负责处理所有写请求
- 日志复制：Leader把日志复制到所有Follower
- 安全性：保证日志的一致性
Raft的选举机制很有意思。每个节点有超时时间，谁先超时谁发起选举。得票过半的成为Leader。Leader会定期发心跳，告诉其他人「我还活着」。
对比总结：
| 维度 | Paxos | Raft |
|---|---|---|
| 理解难度 | 高 | 低 |
| 工程实现 | 复杂 | 相对简单 |
| Leader角色 | 可选 | 必须 |
| 日志复制 | 不强制顺序 | 严格顺序 |
你可能会问：「那实际项目中用哪个？」嗯，ZooKeeper用的是Zab协议，它和Raft很像，但细节不同。我个人建议，如果你要自己实现一致性协议，选Raft。Paxos更适合做理论研究。
4.3 Leader选举机制
Leader选举是分布式系统的核心问题之一。谁当Leader？怎么选？选出来之后怎么保证唯一性？
4.3.1 ZooKeeper的Leader选举
ZooKeeper集群启动时，或者当前Leader挂了，就会触发选举。选举过程大致如下：
- 每个节点把自己投票给自己，然后广播给其他节点
- 节点收到投票后，比较ZXID（事务ID）和myid（节点ID）
- ZXID大的优先，ZXID相同则myid大的优先
- 得票超过半数的节点成为Leader
避坑指南：我曾经遇到过一个问题——集群节点数配置成偶数。结果网络分区时，两边各一半节点，谁也选不出Leader。后来我改成奇数节点，问题就解决了。记住：ZooKeeper集群节点数最好是奇数，2n+1台能容忍n台故障。
4.3.2 Raft的Leader选举
Raft的选举机制更简洁：
- 节点有三种状态：Leader、Follower、Candidate
- Follower如果超时没收到Leader心跳，就变成Candidate
- Candidate给自己投票，并发起选举请求
- 收到多数派投票的Candidate成为Leader
Raft的选举超时时间是随机的（150-300ms），这能有效避免多个节点同时发起选举导致的「选票分裂」问题。
核心区别：ZooKeeper的选举依赖ZXID和myid，Raft依赖任期号（term）和日志索引。ZooKeeper的选举更「重量级」，Raft更「轻量级」。
4.4 实际应用中的选择
说了这么多理论，到底怎么选？我个人的建议是：
- 如果你需要成熟的协调服务：直接用ZooKeeper，别自己造轮子
- 如果你在实现分布式存储系统：考虑Raft，比如etcd、Consul都是基于Raft的
- 如果你在做学术研究：可以深入Paxos，它的理论价值很高
再次提醒：不要在生产环境自己实现一致性算法。我见过太多「自己写Paxos」的悲剧了。用现成的、经过验证的实现，它不香吗？
好了，这一章的内容就到这里。下一章我们会聊聊分布式存储系统的设计，包括数据分片、副本管理、CAP理论的实际应用。到时候见。