分布式大牛详解Zookeeper底层原理

很多学员都在反馈，说zk很难学，学的不是很明白，在这里，我继续带着大家详解一遍Zookeeper

首先zk是什么呢首先肯定是一个个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用 中经常遇到的一些数据管理问题，如：统一命名服务、集群管理、分布式应用配置项的管理 等。

第二：Zookeeper是一个数据库 

第三：Zookeeper是一个拥有一件系统特点的数据库

第四：Zookeeper是一个解决了数据一致性问题的分布式数据库 

第五：Zookeeper是一个具有发布和订阅功能的分布式数据库 (watch)

这样说同学们应该都是认同的吧，没有异议的吧

那么这个一致性又是什么呢

一致性分为强一致性，弱一致性， 最终一致性

有些同学不是很懂哈，那就接着看下面的内容

强制要求步骤2读取的时候，一定要读取的是2，不能读取到的是1，那么要求数据库之间同步异常迅速或者在步骤2上加锁以等待数据同步完成，那么这种叫强一致性；

允许步骤2读取的时候，可以读取的是1，那么这种叫弱一致性，其实就是不需要要一致；

允许步骤2读取的时候，可以先读到 1，过一段时间再读到2，那么这种叫最终一致性，就是可以等待一段时间才一致；

一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后才能正常的对外提供服务。

保证了强一致性，通常需要损耗可用性

CAP也可分为三个，

Consistency：一致性（强一致性）

 Availability：可用性

 Partition Tolerance：分区容错性

分区容错性指的是即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够适应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔为独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。

简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。“如果说Spanner真有什么特别之处，那就是谷歌的广域网。Google通过建立私有网络以及强大的网络

工程能用来保证P，在多年运营改进的基础上，在生产环境中可以最大程度的减少分区发生，从而实现高可用性。”

                                                                                                                                             –CAP之夫
那么问题来了，CAP能同时满足吗？

CAP如果同时满足就代表：当一个分布式系统内部网络出现了问题后，这个分布式系统还能保证系统可用以及数据一致。

目前为止，因为网络的问题，CAP是不能同时满足的

CP WITHOUT A这种情况在分布式系统中几是不存在的。首先在分布式环境下，网络分区是一个自然的问题。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。

一个保证了CP而舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

按场景进行选择可分为：•钱财安全（CP）跟用户体验(AP)（保留分区容错性和可用性，舍

弃一致性）BASE理论

基本可用（Basically Available）：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级⻚⾯，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态（ Soft State）：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

最终一致性（ Eventual Consistency）：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。日常生活中是怎么解决一致性的呢

领导说：“今天下午3-4点，大会议室开会，做一下未来规划，收到请回复”

看到通知的同事回复“1”

而领导他会看有多少人回复了他这条通知，如果说回复的人太少，他可能会再次进行通知，如果说回复的人比较多了，他就放心了，他并不会统计是不是所有人都回复了

等到下午3点，所有同事一起做未来的规划

部门就是一个服务器集群，这个集群中有领导和同事两种⻆色

• 领导是由同事选举出来的

• 领导负责从外部接收请求，然后开会时同步信息给同事

• 领导需要先确定是不是同事有空开会，所以先在群里问一下所有同事，并统计同事的回复，但是领导并不需要收到所有人的回复，只需要一部分人的回复就可以了

• 确定大部分同事都有空了，就可以确定3点开会并同步信息了

保证一致性的要素

领导：领导者选举机制

两阶段提交：

过半验证机制：

集群节点⻆色

• Leader：领导者

• Follower：跟随者

• Observer：观察者

现实生活中的选举场景

• 1. 我跟谁关系好，我投给谁

• 2. 我觉得谁厉害，我投给谁

• 3. 我可以更新我的投票，通过和别⼈讨论，发现别人投的那个人比我现在投的这个人要厉害，我修改我的投票，投更厉害的。

• 4. 从投票箱统计投票，获得投票数最多者为领导

领导者选举发生的结点

• 集群启动

• Leader挂掉

• Follower挂掉后Leader发现已经没有过半的

Follower跟随自己了-不能对外提供服务了（领导者选举）

领导者选举

领导者选举的过程实际上就是比较哪台服务器比较强，比较规则是：1. 谁的数据比较新谁当领导（zxid），2.数据都一样则看谁的服务器Id（myid）比较大，谁就是领导；这个过程是通过各个服务器之间相互投票来进行的，每台服务器会接收其他服务器的投票，在投票信息里就会包含上面说的两个信息zxid， myid，然后进行PK，选出谁比较强，而PK中弱的那一方修改自己的投票，改为投刚刚和自己PK赢的一方，所以按照这个规则，每台服务器都会有一个自己认为最强的那个人，而在整个投票的过程中，每台服务器内部都会存在一个投票箱，该投票箱内存放了其他服务器当前投给了谁，所以每台服务器可以根据这个投票箱内的数据来看是否有超过半数的服务器和我当前投的最强者是同一台服务器，如果超过了则认为选出了Leader（自己当前所投的那个最强者即为Leader），如果发现自己就是这个最强者，则进行领导，如果自己不是，则进行跟随（Follower）。

写数据流程

满足CP

ZK会将接收到的请求预先放在一个队列中，然后用单线程从队列中依次取出请求进行处理，比如同时有两个写操作进行了队列，那么第一个写操作在被处理的过程中，第二个写操作是需要等待第一个写操作处理完后才会被处理的，这对于第二个写操作而言就是集群暂时不可用，二不可用的主要原因就是第一个写操作为了使集群中的数据保持一致正在进行二阶段提交操作。

领导者选举的时候可以处理写请求吗？

脑裂出现的原因是一部分服务器和领导失去了连接，而这个一部分服务器之间是可以相互连通的，所以这个部分服务器会重新选举，如果重新选举出来了一个Leader，那么整个集群就出现了两个Leader，这就是脑裂。

Zookeeper中的领导者选举需要收到超过一半的服务器的选票，所以如果出现了脑裂，服务器的节点数量是不够的，所以通过过半机制的验证，避免了脑裂。

ZAB协议

• 领导者选举

• 数据同步（恢复阶段）

• 接收请求（二阶段提交）

同期视频连接：https://www.bilibili.com/video/av73279922

本文由博客一文多发平台 OpenWrite 发布！