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执行本地事务