Zookeeper的详细介绍

Zookeeper的详细介绍

1. Zookeeper概述

zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅，负载均衡，命名服务，集群管理分布式锁和分布式队列等功能

2. 分布式数据一致性

数据一致性分为强一致性和最终一致性，强一致性指的是如果数据不一致，就不对外提供数据服务，保证用户读取的数据始终是一致的，而最终一致性只要数据最终同步即可，没有实时性要求，数据一致性只要通过锁机制即可解决

3. CAP原则

CAP在分布式系统中指的是一致性，可用性和分区容错性
① 一致性：指的是强一致性
② 可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定的响应时间内响应请求，超出时间范围认为是系统不可用
③ 分区容错性：分布式系统在遇到任何网络分区故障的时候，需要能够保证对外提供一致性和可用性服务，除非是整个网络都发送故障
在一个系统中只能满足以上三点中的起重工两点，在分布式网络应用中，要么是AP模型要么是CP模型

4. 一致性协议

（1）2PC二阶段提交

阶段一：提交事务请求
① 协调者向所有参与者节点发送事务内容，询问是否可以执行事务操作，并等待其他参与者节点的反馈
② 各个参与者节点执行事务操作
③ 各个参与者节点反馈给协调者，事务是否可以执行
阶段二：事务提交
根据第一阶段各个参与者节点反馈的ack，如果所有参与者节点反馈ack，则执行事务提交，否则中断事务
事务提交
① 协调者向各个参与者节点发送commit请求
② 参与者节点接收到commit请求后，执行事务的提交操作
③ 各个参与者节点完成事务提交后，向协调者发送commit成功确认信息
④ 协调者接收各个参与者节点的ack后，完成事务的commit
中断事务：
① 发送回滚请求
② 各个参与者节点回滚事务
③ 反馈给协调者事务回滚结果
④ 协调者接收各个参与者节点ack后回滚事务
存在的问题：
① 同步阻塞：二阶段提交过程中，所有参与事务操作的节点处于同步阻塞状态，无法进行其他的操作
② 单点问题：一旦协调者出现单点故障，无法保证事务的一致性操作
③ 脑裂导致数据不一致：分布式节点出现网络分区，某些参与者未收到commit提交命令，则出现部分参与者完成数据提交，未收到commit的命令的参与者无法提交事务提交，出现数据不一致现象
（2）3CP三阶段提交

阶段一：canCommit
① 进行事务询问
② 各个参与者节点想协调者反馈事务询问的响应
阶段二：preCommit
1）执行事务预提交
① 发送预提交请求：协调者向所有参与者节点发送preCommit请求，进入prepared阶段
② 事务预提交：各个参与者节点接收到preCommit请求后，执行事务操作
③ 各个参与者节点向协调者反馈事务执行
2）中断事务
任意一个参与者节点反馈给协调者响应No时，或者在等待超时时，协调者还未收到参与者的反馈，就中断事务
① 协调者向各个参与者节点发送abort请求
② 参与者收到abort请求或者在等待超时时中断事务
阶段三：doCommit
1）执行提交
① 发送提交请求：协调者向所有参与者节点发送doCommit请求
② 事务提交：各个参与者节点接收到doCommit请求后执行事务提交操作
③ 反馈事务提交结果：各个参与者完成事务提交后，向协调者发送ack
④ 事务完成：协调者接收各个参与者反馈的ack，完成事务
2）中断事务
① 参与者接收到abort请求后，执行事务回滚
② 参与者完成事务回滚后，向协调者发送ack
③ 协调者接收回滚ack后，回滚事务
3CP解决了协调者挂掉后参与者无限阻塞和单点问题，但无法解决网络分区问题

5. Paxos算法

（1）Paxos算法是一种提高分布式系统容错性的一致性算法，解决了3PC中网络分区的问题，同时Paxos算法引入过半概念即少数服从多数原则
（2）Paxos的四种角色三种行为
① client：系统外部角色，请求发起者，不参与决策
② proposer：提案提议者
③ acceptor：提案的表决者，半数原则
④ learners：提案的学习者，当提案被选定后，其同步执行提案，不参与决策
（3）Paxos算法的两个阶段

（4）Paxos算法的问题解决
① 正常流程

② 出现单点故障，acceptor部分节点失效，半数原则

③ proposer失效
会重新生成proposer，并且编号会加一

④ 活锁问题
类似于两人面对面走路，让自己和别人不相碰又没有相对走过去，proposer和acceptor的编号会相对的相继加一

6. ZAB协议

（1）是一种支持崩溃恢复的原子广播协议，基于Fast Paxos实现。
（2）zookeeper使用单一主进程leader用于处理写请求；集群采用ZAB原子广播协议，以事务提交proposal的形式广播到所有follower，若是读请求，则leader直接处理；还有一种情况是直接对follower进行读写操作，如下图所示

7. zookeeper的三种角色

（1）Leader：处理集群的写请求，并发起投票，只有超过半数的节点同意后才会提交该写请求
（2）follower：处理读请求，响应结果，转发写请求到Leader，在选举leader过程中参与投票
（3）observer：没有投票权的follower，协作follower处理读请求，当整个zk集群读请求负载很高时，需要增加follower节点会让leader在提出写请求提案时，需要半数以上的follower投票节点同意，会增加leader和follower的通信压力，降低写操作效率

8. zookeeper的两种模式

（1）恢复模式
当服务启动或领导崩溃后，zk进入恢复状态，选举leader，leader选出后 ，将完成leader和其他机器的数据同步，当大多数server完成和leader同步后，恢复模式结束
（2）广播模式
一旦leader以及和大多数的follower进行同步后，进入广播模式，如果有新加入的机器，会自动从Leader中同步数据。Leader在接收客户端请求后，会产生事务提案广播给其他机器，有超过一半的follower同意该提案再提交事务
注意在ZAB的事务的二阶段提交中，移除了事务中的中断，follower要么ack，要么放弃，leader无需等待所有的follower的ack。

9. zxid

是64位长度的Long类型，高32位为纪元epoch，低32位为事务标识xid，即zxid由两部分构成：epoch和xid
每一个leader都有不同的epoch值，每一个新的选举开启时都会生成一个新的epoch，新的leader产生会更新所有的zkServer的zxid的epoch，xid是一个依次递增的事务编号。

10. Leader选举算法

选举三大核心原则
（1）zookeeper集群中只有超过一半以上的服务器启动，集群才能正常工作
（2）集群正常启动工作之前，myid小的服务会给大的服务器进行投票，持续到集群正常工作，选出leader
（3）选择leader之后，之前的服务器状态由looking改为following，以后的服务器都是follower
启动流程：

奔溃与恢复
leader挂掉后，集群中其他follower会将following变为looking，重新进入leader选举，leader选举同上启动流程

11. 消息广播算法

一旦进入广播模式，集群中非leader节点中接收到事务请求，首先会把事务请求转发给服务器，Leader服务器为其对应的事务提案proposal，并发送给集群中其他节点，如果过半则事务提交

① Leader接收到消息后，消息通过全局唯一的64位自增事务id，zxid标识
② leader发送给follower的提案是有序的，leader会创建一个FIFO队列，将提案顺序写入队列中发送给follower
③ follower接收到提案后，会比较提案zxid和本地事务日志最大的zxid，若提案zxid比本地事务id大，将提案记录到本地日志中，反馈ack给leader，否则拒绝
④ Leader接收到过半ack后，leader想所有的follower发送commit，通知每个follower执行本地事务