ZooKeeper为什么是CP

一、ZooKeeper 是如何实现数据一致性的呢？

ZooKeeper通过【ZAB协议】实现数据一致性，确保分布式场景中的数据更新在集群中是有序、一致和可靠的。

ZAB协议保障一致性的使用场景：

1、ZooKeeper集群中如果出现【Follower节点崩溃】或者【Leader进程崩溃】时，
都会通过Zab协议来保证数据一致性
2、ZooKeeper的【Watcher机制】分布式事件通知，这些特性都依赖ZooKeeper的【Zab协议】   
3、ZooKeeper的数据同步，或者选举新的Leader节点后，数据同步。

ZooKeeper的ZAB协议有两种模式：消息广播模式和崩溃恢复模式

二、消息广播模式

1、ZooKeeper中的一个节点被选为leader节点，它接收来自客户端的【事务提交】请求，并将这些请求作为【提议】广播给其他follower节点。
2、每个follower节点收到提议后会进行反馈给Leader节点
3、Leader节点根据收集到的反馈决定【是否执行】广播Commit操作。

为了保证数据一致性，ZooKeeper广播阶段使用了【quorum选举机制】来根据【大多数节点】上结果是否commit。

流程：

leader节点的写入操作也是两步操作，首先，1、广播事务操作，2、广播提交操作。

1、在这里，"超过半数"指的是反馈的节点数大于或等于【follower节点总数的一半加一】，
follower节点总数为N,那么就是【N/2+1】,注意从节点一般都是偶数。

2、最后Leader节点将【广播commit信息】发给Follower确认并提交,Follower收到 commit 之后，完成各自的事务提交。

三、崩溃恢复模式

崩溃阶段条件：

1、初始化集群，刚刚启动的时候
2、Leader 崩溃，因为故障宕机
3、Leader 失去了半数的机器支持，与集群中超过一半的节点断连

在这个阶段，ZooKeeper会【进行leader选举】、【数据同步】操作以保持集群中的数据一致性。
举产生新的Leader会与过半的 Follower 进行同步，使数据一致，当与过半的机器同步完成后，就退出恢复模式， 然后进入消息广播模式。

如何完成的【Leader选举】和【数据同步】?

流程

1、各个节点变更状态，变更为【Looking】

ZooKeeper 中除了 Leader 和 Follower，还有 Observer 节点，Observer 不参与选举，Leader
挂后，余下的 Follower 节点都会将自己的状态变更为 Looking，然后开始进入 Leader 选举过程。

2.各个 Server 节点都会发出一个投票参与选举

在第一次投票中，所有的 Server 都会投自己，然后各自将投票发送给集群中所有机器，在运行期间，
每个服务器上的事务ID【Zxid】 大概率不同。

3.集群接收来自各个服务器的投票，开始处理投票和选举

处理投票的过程就是对比 Zxid 的过程，假定 Server3 的 Zxid 最大，Server1判断 Server3 可以成为 Leader，那么 Server1 就投票给 Server3

判断的依据如下：
1、首先选举 epoch 最大的，也叫【时间戳】
2、如果 epoch 相等，则选 zxid 最大的
3、若 epoch 和 zxid 都相等，则选择 server id 最大的，就是配置 zoo.cfg 中的myid
在选举过程中，如果有节点获得超过半数的投票数，则会成为 Leader节点，反之则重新投票选举。

4.选举成功，改变服务器的状态，并把Leader数据同步给Follower

在崩溃恢复阶段完成选举后，接下来的工作是数据同步。在选举过程中，通过投票可以确认具有最大Zxid的节点作为Leader服务器。而同步阶段则利用Leader在之前阶段获取的最新【提议】历史，将其同步给集群中的所有副本

四、总结

总结起来，ZooKeeper的ZAB协议，利用【消息广播阶段】和【崩溃恢复阶段】来实现数据一致性。

1、在消息广播阶段，leader节点接收和广播事务请求，并根据大多数节点的反馈决定是否进行commit。
2、崩溃恢复阶段，当leader不可用时，进行leader选举和数据同步操作。Zxid是ZAB协议中的一个重要概念，用于【标识事务的编号】和【确定leader周期】。

通过这些机制，ZooKeeper保证了在分布式场景下数据的一致性和可靠性。

1、ZooKeeper 的【事务功能】通常在以下一些场景中被使用：

1、配置管理

在分布式系统中，配置的一致性是非常重要的。ZooKeeper可以用于存储和管理系统的配置信息，而事务可以确保配置的原子性和一致性。例如，当需要更新配置时，可以使用ZooKeeper 的事务功能确保配置的更新是原子的，避免配置的部分更新或不一致。

2、分布式锁

ZooKeeper的临时顺序节点和事务功能可以用于实现分布式锁。每个参与者可以创建一个临时顺序节点，表示它想要获取锁。通过对这些节点的顺序进行比较，可以确定哪个节点获得了锁。使用ZooKeeper 的事务功能可以确保在获取锁的过程中的各个步骤是原子的，从而避免竞争条件和不一致。

3、分布式队列

在一些场景中，ZooKeeper的事务功能可以用于实现分布式队列。通过在队列中添加和删除节点，可以确保对队列的操作是原子的，从而维护队列的一致性。

五、WARO机制和Quorum机制

Quorum机制

1、WARO机制

这个机制zk并没有使用

一种简单的副本控制协议，写操作时、只有【当所有的副本】都更新成功之后，
这次写操作才算成功，否则视为失败。

1、对于写服务来书：只要有一个副本宕机了，写服务就不会成功。牺牲了【更新服务的可用性】
2、但是对于读服务来说：可用性非常高，因为只要有一个节点存活，读不需要多个节点参与、
仍能提供读服务，而且数据都是一致的。

2、Quorum机制

10个副本，一次成功更新了三个，那么至少需要读取八个副本的数据，可以保证读到了最新的数据。为什么说要读8个节点，因为有7个节点没有更新成功，多读一个节点，那么肯定是会拿到最新数据的，最新的数据，怎么辨别就是，就是通过【一个版本号】，多次读取的时候，只需要判断哪个版本号最新，就可以了。

zookeeper是保障大多数成功成功，就包含半数以上，所以zookeeper在读区数据的时候，一定要保障半数以上的读取操作，并且取版本最新的数据。

无法【保证强一致性】，也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。需要配合一个获取最新成功提交的【版本号】的metadata服务，这样可以确定最新已经成功提交的版本号，然后从已经读到的数据中就可以确认最新写入的数据

原文：跳转