zookeeper的zab协议解决的问题与设计方案

故事的开始

如果从 Lamport 的 basic paxos算法开始捡起来还是有点复杂。我建议从单机开始讲起，对产品不停地迭代。

最简单的场景

假如，现在我们有一套5个人，需要修改一个变量的值，那就存在竞争问题了。

每个人修改值都会做3件事情，那就是读\计算\写。

那么就存在一个问题，如果5个人同时对这个变量读写该以谁为准呢？。

（我们为了不复杂化我们的系统设计，所以第一个版本，我们【把变量寄放在一块共享内存】）

第一个游戏规则

如果5个人同时对这个变量读写该以谁为准呢？

为了简单粗暴，我们会以最大的为准（像比特币的话，就是以区块链最长的为准，我们这里没有女巫攻击，所以可以简单粗暴点）。

第一个并发修改值的问题得到了解决。

特点：这样做出来的集群，具备了读写一致性，以及实时有效性。也就说无论什么时候，客户端都能读取到有效值，而且服务器某一瞬间分发给客户端的值，永远都是一样的。

缺点：

• 共享内存是单机的，不具备高可用。
• 共享变量无法正常update,只能单调递增，不服合正常业务场景。

版本号的出现

• 为了能够支持正常的业务update，我们决定用变量的高64位座位版本ID，真正的数值放在低32位。这样就可以继续“以最大数为准”，而且又不影响我们读写业务数据。mysql和zk的事务都是这样做的（包括比特币也是）。

分区的出现

为了高可用，我们把数据存放在多个节点。这就意味着，每次提交写事务，都得到所有节点进行同步，这个过程我们称之为【广播消息】

从设计来看，我们实现了分布式存储，我们的数据在每一个存储节点都有一个副本。这就是所谓的分区。（复杂的分区都是跨地域机房的）