zookeeper-2 ZAB协议

zk如果是单点服务, 则不涉及到分布式同步协议的问题, 所有的数据都有一个节点处理即可, 该节点用来同步客户端分布式集群中的消息同步, 然而单点是不可靠的, zk本身也要实现分布式集群以保证高可用高并发的特性. 所以zk自身的分布式集群间的数据同步问题采用了ZAB协议实现, 而对客户端而言, 一个zk集群被视为一个稳定运行的单节点即可

简言之, zk的分布式数据一致性问题依靠ZAB协议实现, 而客户端的分布式一致性问题由zk来实现

 

关于ZAB协议:(zk只能有一个leader, 其用来负责广播事务请求)

 

1.ZAB协议包括两种基本模式:  崩溃恢复和广播模式. 其中奔溃恢复包括选举新leader和数据同步两个阶段

2.消息广播过程:

  1) leader服务器会为每个事务请求生成一个proposal, 并为其生成一个单调递增的唯一事务ID(ZXID)

  2) leader服务器为每一个follower生成一个单独的FIFO消息队列, 将proposal放入消息队列中

  3) 每个follower在接收到proposal后将其写入本地磁盘的事务日志中, 并在成功写入后给leader服务器一个ACK相应信号,此时在磁盘就已经存在了事务ID, 以此作为以后的leader选举标准

  4) leader在接收到超过半数的ACK信号后向follower发送一个commit信号, 同时完成自身事务提交

  5) follower在接收到commit信号后完成自身事务提交, (事务提交的意义:将写入到本地磁盘中的日志数据放入到内存数据库中, 客户端使用)

3. zk集群进入崩溃恢复模式的情况: leader崩溃或者由于网络原因导致leader与过半数follower通信联系

4.ZAB协议中保证的两个特性

   1) 确保已经在leader服务器上提交的事务最终被所有服务器提交(执行完2中的第三步)

   2) 确保丢弃那些只在leader服务器上提出的事务(执行完2中的第一步)

5.  针对ZAB协议执行的崩溃恢复过程

   1)选举出follower中具有最大事务ID的节点为新的leader, 对该最大事务ID生成新的事务ID

   2)选举出新的leader后将进行数据同步, 数据同步的过程包括数据更新(ZAB协议中第一特性)和数据回退(ZAB协议中的第二特性)

 

6.事务ID的生成策略

 

CAP理论告诉我们,一个分布式系统不可能同时满足以下三种

一致性(C:Consistency)
可用性(A:Available)
分区容错性(P:Partition Tolerance)

这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中。

在此ZooKeeper保证的是CP

分析:可用性(A:Available)

不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。


zk与eureka作为服务注册中心对比:

ZooKeeper是分布式协调服务,它的职责是保证数据(注:配置数据,状态数据)在其管辖下的所有服务之间保持同步、一致. 所以其舍弃了可用性; 在服务注册中主要的缺点:

1) leader选举阶段不提供对外服务

2) 网络延迟造成的临时节点注销, 而实际该注册服务是可用状态

3) 少于半数节点不提供对外服务

eureka是一个不满足一致性的注册中心

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性),其中说明了,eureka是不满足强一致性,但还是会保证最终一致性,所以可以得出一个结论,eureka不是不满足一致性,只是在同等情况下,eureka会首先保证可用性,在一定程度内再去进行一致性的同步

 

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值