聊聊Zookeeper的数据一致性解决方案

个人认为Zookeeper就是一个数据库，一个分布式数据库，一个具有文件系统特征的分布式数据库，一个提供监听机制的具有文件系统特质的分布式数据库。

如果跟大家聊Zookeeper，那就避不开 领导者选举 、 CAP 、 ZAB协议 、 数据一致性 这些概念。但事实上，这些概念中最核心的是数据一致性，CAP中的C代表的就是强一致性，ZAB协议就是用来保证数据一致性的，而大家熟知的 领导者选举只是ZAB协议中的一个阶段 而已。

所以，我们直接开门见山，来直接聊一聊Zookeeper是如何保证数据一致性的。

关于Zookeeper的数据一致性的场景演示，本文就不演示了，读者可以直接搭一个Zookeeper集群，然后用多个客户端连不通的ZkServer，通过不同的客户端，去操作的不同的ZkServer，你会发现，直接被操作的ZkServer上的数据变化会被同步到集群里的其他ZkServer上，这就是一致性的表现。

那么问题是， Zookeeper的这种数据一致性是怎么实现的呢 ？

其实，我们日常生活中涉及到很多关于数据一致性的场景，比如你和你公司的小伙伴，你们可能是组员，可能是部门同事，假如你们是组员，所以你们会有组长，假设你就是组长，那么很有可能你需要把从客户那里，或产品经理那里获得的信息通过开会的形式告诉给你的组员，比如今天，你决定今天下午3点给组员开会，那么你可能今天上午在你们群里先会通知一下，会发一条信息：“今天下午3点，开会说一下产品经理的新需求，收到请回复”，如果你看到组员都回复了，那么你就可以准备准备下午3点正式开会了，那么这个场景其实就是一个一致性问题，你获得的信息需要同步给其他组员。

好了，我们认真的来想一下这个场景。

• 首先，我们的目标是：信息同步，信息一致
• 其次，我们的方法是：先在群里预先通知，然后正式开会
• 最后，我们的结果是：组内所有的组员都获得了同样的信息

这个场景中有两个角色：

1. 组长
2. 组员 所用的方法有两个阶段：
3. 预先通知（注意，这里组长需要看到组员的回复，但是他并不需要去统计 是不是所有组员都回复了 ，他只需要看到 大部分组员回复了 ，他就认为这个会可以开了）
4. 正式执行

所以，我们可以想到，对于保证数据的一致性，其实有三个要素

1. 需要一个领导（组长），所以需要一个领导者选举机制
2. 需要一个数据同步方法，其实就是2PC（1. 预提交，2. 收到ACK，3. 提交）
3. 需要一个回复验证机制，过半机制验证

这么一分析下来，不知道大家对于一致性的解决方案有没有自己的理解了，这里没有涉及到Zookeeper的源码分析，存理论分析，大家可以把自己的理解评论出来，一起讨论。