分布式理论、算法与协议是理解分布式系统的基础。学习这部分内容时，不建议只背结论，更重要的是理解不同方案在一致性、可用性、容错、性能和工程复杂度之间的取舍。

适合谁看

• 想系统理解分布式一致性、共识算法和数据分布的后端开发者。
• 准备分布式系统、系统设计、后端架构面试的同学。
• 对 CAP、BASE、Paxos、Raft、ZAB、Gossip 等概念只停留在“背过”的读者。
• 需要理解 ZooKeeper、Redis Cluster、分布式缓存和服务发现底层机制的工程师。

学习重点

开始之前，先说两个常见的场景：

1. 负载均衡：由于访问人数太多，我们的网站部署了多台服务器个共同提供相同的服务，但每台服务器上存储的数据不同。为了保证请求的正确响应，相同参数（key）的请求（比如同个 IP 的请求、同一个用户的请求）需要发到同一台服务器处理。
2. 分布式缓存：由于缓存数据量太大，我们部署了多台缓存服务器共同提供缓存服务。缓存数据需要尽可能均匀地分布式在这些缓存服务器上，通过 key 可以找到对应的缓存服务器。

这两种场景的本质，都是需要建立一个从 key 到服务器/节点的稳定映射关系。

背景

在分布式系统中，不同节点间共享状态是一个基本需求。

一种简单的方法是 集中式广播：由中心节点向所有其他节点同步信息。这种方式适合中心化系统，但存在明显缺陷：当节点数量增加时，同步效率下降（O(N) 复杂度），且过度依赖中心节点，存在单点故障风险。

分散式传播 的 Gossip 协议 提供了一种去中心化的替代方案。

背景

Paxos 算法是 Leslie Lamport（莱斯利·兰伯特）在 1990 年提出的一种分布式系统 共识 算法。这是最早被广泛认可的分布式共识算法之一（前提是不存在拜占庭将军问题，也就是没有恶意节点）。

为了介绍 Paxos 算法，兰伯特专门写了一篇幽默风趣的论文。在这篇论文中，他虚拟了一个叫做 Paxos 的希腊城邦来更形象化地介绍 Paxos 算法。

不过，审稿人并不认可这篇论文的幽默。于是，他们就给兰伯特说：“如果你想要成功发表这篇论文的话，必须删除所有 Paxos 相关的故事背景”。兰伯特一听就不开心了：“我凭什么修改啊，你们这些审稿人就是缺乏幽默细胞，发不了就不发了呗！”。

本文由 SnailClimb 和 Xieqijun 共同完成。

1 背景

在如今的互联网架构中，为了扛住海量流量，系统往往需要横向堆机器。机器一多，宕机、断网这些破事就成了家常便饭。怎么让这群随时可能掉线的服务器保持步调一致，不对外提供错乱的数据？这就轮到分布式共识算法出场了。

作为一款极其优秀的分布式协调框架，ZooKeeper 的高可用和数据一致性备受业界推崇。很多人误以为 ZooKeeper 使用的是大名鼎鼎的 Paxos 算法，但实际上，它的“灵魂”是一个专门为其定制的共识协议——ZAB（ZooKeeper Atomic Broadcast，原子广播协议）。

ZAB 并非像 Paxos 那样是通用的分布式一致性算法，它是一种特别为 ZooKeeper 设计的、支持崩溃可恢复的原子消息广播算法。基于 ZAB 协议，ZooKeeper 实现了一种主备模式的架构，来保持集群中各个副本之间的数据一致性。