Zookeeper数据一致性底层算法分析

一、zookeeper概述

  • 1、zookeeper:是一个开源的、分布式的,为分是不是框架提供协调服务的Apache框架。

  • 2、zookeeper工作机制:基于观察者模式设计的分布式服务管理框架,负责存储和管理大家都关心的数据,然后接收观察者的注册,一旦数据状态发生变化,zookeeper将负责通知已经在zookeeper上注册的那些观察者做出相应的反应。

  • 3、zookeeper特点:

    • 一个领导者leader,多个跟随着follower组成的集群。
    • 集群中只要有半数以上节点存活,zookeeper集群就能正常服务,所以zookeeper适合按照奇数台服务器。
    • 全局数据一致:每个server保存一份相同的数据副本,client无论连接到哪个server,数据都是一致的。
    • 更新请求顺序执行,来自同一个client的更新请求按其发送顺序依次执行。
    • 数据更新原子性,一次数据更新要么成功,要么失败。
    • 实时性:在一定时间范围内,client能读到最新的数据。
  • 4、zookeeper数据结构:
    zookeeper数据模型的结构与Linux文件系统很类似,整体上可以看作是一颗树,每个节点称作一个znode。每一个znode默认能够存储1MB的数据,每个znode都可以通过其路径唯一标识。


  • 5、zookeeper应用场景:

    • (1)统一域名服务:在分布式环境下,经常需要对服务进行统一命名,便于识别。
    • (2)统一配置管理:在分布式环境下,配置文件同步。
    • (3)统一集群管理:在分布式环境下,实时掌握每个节点的状态。
    • (4)软负载均衡:zookeeper记录每台服务器的访问次数,让访问次数最少的服务器去处理最新的客户端请求。
  • 6、zookeeper配置文件:zoo.cfg

    • (1)tickTime=2000:通信心跳时间,zookeeper服务器与客户端心跳时间,单位ms。
    • (2)initLimit=10:lf初始化通信时限。
    • (3)syncLimit=5:lf同步通信时限。
    • (4)dataDir:保存zookeeper中的数据。默认的tmp目录。
    • (5)clientPort=2181:客户端连接端口,通常不做修改。

二、zookeeper选举机制

1、第一次启动选举机制

  • (1)服务器1启动,发起一次选举。服务器1投自己一票。此时服务器1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为LOOKING;

  • (2)服务器2启动,再发起一次选举。服务器1和2分别投自己一票并交换选票信息;此时服务器1发现服务器2的myid比自己目前投票推举的(服务器1)大,更改选票为推举服务器2。此时服务器1票数0票,服务器2票数2票,没有半数以上结果,选举无法完成,服务器1,2保持LOOKING;

  • (3)服务器3启动,发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票,服务器2为0票,服务器3为3票。此时服务器3的票数已经超过半数,服务器3当选leader。服务器1,2更改状态为FOLLOWING,服务器3更改状态为LEADING;

  • (4)服务器4启动,发起一次选举。此时服务器1,2,3已经不是LOOKING状态,不会更改选票信息。交换选票信息结果:服务器3为3票,服务器4为1票。此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING;

  • (5)服务器5启动,同4一样当小弟。

2、非第一次启动选举机制

  • (1)当zookeeper集群中的一台服务器出现以下两种情况之一时,就会开始进入leader选举;
    • 服务器初始化启动
    • 服务器运行期间无法和leader保持连接
  • (2)而当一台机器进入leader选举流程时,当前集群也可能会处于以下两种状态;
    • 集群中本来就已经存在一个leader
      对于第一种已经存在leader的情况,机器试图去选举leader时,会被告知当前服务器的leader信息,对于该机器来说,仅仅需要和leader机器建立连接,并进行状态同步即可。

    • 集群中确实不存在leader
      假设zookeeper由5台服务器组成,SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是leader。某一时刻,3和5服务器出现故障,因此开始进行leader选举。

选举机制总结:

半数机制,超过半数的投票通过,即通过。

  • (1)首次启动选举规则:投票过半数时,服务器id大的胜出。
  • (2)非首次启动选举规则:EPOCH大的直接胜出;EPOCH相同,事务id大的胜出;事务id相同,服务器id大的胜出。

三、zookeeper节点类型

  • 1、持久:客户端与服务器断开后,创建的节点不删除

    • (1)持久化目录节点
      客户端与zookeeper断开连接后,该节点依旧存在。
    • (2)持久化顺序编号目录节点
      客户端与zookeeper断开后,该节点依旧存在,只是zookeeper给该节点名称进行顺序编号
    • (3)临时目录节点
      客户端与zookeeper断开后,该节点被删除
    • (4)临时顺序编号目录节点
      客户端与zookeeper断开后,该节点被删除,只是zookeeper给该节点名称进行顺序编号
  • 2、短暂:客户端与服务器断开后,创建的节点自己删除

四、zookeeper监听器原理

  • 1、首先要有一个main()线程;
  • 2、在main线程中创建zookeeper客户端,这时就会创建两个线程,一个负责网络连接通信(connect),一个负责监听(listener);
  • 3、通过connect线程将注册的监听事件发送给zookeeper;
  • 4、在zookeeper的注册监听器列表中将注册的监听事件添加到列表中;
  • 5、zookeeper监听到有数据或路径变化,就会将这个消息发送给listener线程;
  • 6、listener线程内部调用了process()方法。

五、服务器动态上下线

客户端能实时洞察到服务器上下线的变化

六、zookeeper分布式锁实现

分布式锁实现原理:


七、顺序一致性

之前提到了Zookeeper集群中是读写分离的,只有Leader节点能处理写请求,如果Follower节点接收到了写请求,会将该请求转发给Leader节点处理,Follower节点自身是不会处理写请求的。

Leader节点接收到消息之后,会按照请求的严格顺序一一的进行处理。这是Zookeeper的一大特点,它会保证消息的顺序一致性。

举个例子,如果消息A比消息B先到,那么在所有的Zookeeper节点中,消息A都会先于消息B到达,Zookeeper会保证消息的全局顺序。

ZXID

ZXID介绍

ZXID是一个long型(64位)整数,分为两部分:epoch(纪元,前32位)和counter(计数器,后32位),是一个全局有序的数字。

  • epoch

    • epoch值随着新leader的产生而变化,每当新选举一个leader,epoch值会自增1。
      如果counter已经达到最大值,即后32位全为1,则进位,此时epoch会自增1。
  • counter

    • 每次committed一个proposal,counter值都会自增1。

ZXID分类:

  • cZxid:创建当前节点时的事务ID。
  • mZxid:最近修改当前节点时的事务ID。
  • pZxid:表示当前节点的子节点列表最后一次修改的事务ID。

那Zookeeper是如何保证消息的顺序?答案是通过zxid。

  • zxid:可以简单的把zxid理解成Zookeeper中消息的唯一ID,节点之间会通过发送Proposal(事务提议)来进行通信、数据同步,proposal中就会带上zxid和具体的数据(Message)。而zxid由两部分组成:

  • epoch: 可以理解成朝代,或者说Leader迭代的版本,每个Leader的epoch都不一样

  • counter:计数器,来一条消息就会自增

这也是唯一zxid生成算法的底层实现,由于每个Leader所使用的epoch都是唯一的,而不同的消息在相同的epoch中,counter的值是不同的,这样一来所有的proposal在Zookeeper集群中都有唯一的zxid。

七、zookeeper底层算法分析

zookeeper如何保证数据一致性?

1、Paxos算法

  • Paxos算法:一种基于消息传递且具有高度容错性的一种一致性算法。

  • Paxos算法解决的问题:如何快速正确的在一个分布式系统中对某个数据值达成一致,并且保证不论发生任何异常,都不会破坏整个系统的一致性。

  • Paxos算法介绍:在一个Paxos系统中,首先将所有节点划分成提议者(proposer),接收者(acceptor),学习者(learner)。(每一个节点都可以身兼数职)。

完整的Paxos算法流程分为三个阶段:

一个完整的Paxos算法流程分为三个阶段:

  • (1)Prepare准备阶段

    • Proposer向多个Acceptor发出Propose请求Promise(承诺)
    • Acceptor针对收到的Propose请求进行Promise(承诺)
  • (2)Accept接受阶段

    • Proposer收到多数Acceptor承诺的Promise后,向Acceptor发出Propose请求
    • Acceptor针对收到的Propose请求进行Accept处理
  • (3)Learn学习阶段

    • Proposer将形成的决议发送给所有Learners

Paxos算法流程:

  • (1)Prepare: Proposer生成全局唯一且递增的Proposal ID,向所有Acceptor发送Propose请求,这里无需携带提案内容,只携带Proposal ID即可。

  • (2)Promise: Acceptor收到Propose请求后,做出“两个承诺,一个应答”。

    • 不再接受Proposal ID小于等于(注意:这里是<= )当前请求的Propose请求。
    • 不再接受Proposal ID小于(注意:这里是< )当前请求的Accept请求。
    • 不违背以前做出的承诺下,回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID,没有则返回空值。
  • (3)Propose: Proposer收到多数Acceptor的Promise应答后,从应答中选择Proposal ID最大的提案的Value,作为本次要发起的提案。如果所有应答的提案Value均为空值,则可以自己随意决定提案Value。然后携带当前Proposal ID,向所有Acceptor发送Propose请求。

  • (4)Accept: Acceptor收到Propose请求后,在不违背自己之前做出的承诺下,接受并持久化当前Proposal ID和提案Value。

  • (5)Learn: Proposer收到多数Acceptor的Accept后,决议形成,将形成的决议发送给所有Learner。

2、ZAB协议

  • ZAB算法:借鉴了paxos算法,是特别为zookeeper设计的支持崩溃恢复的原子广播协议。基于ZAB协议,zookeeper设计为只有一台客户端(leader)负责处理外部的写事务请求,然后leader客户端将数据同步到其他follower节点,即zookeeper只有一个leader可以发起提案。
  • ZAB协议内容:包括两种基本的模式,即消息广播和崩溃恢复。

1、消息广播

具体步骤:

  • (1)客户端发起一个写操作请求。
  • (2)Leader 服务器将客户端的请求转化为事务 Proposal 提案,同时为每个 Proposal 分配一个全局的 ID,即 zxid。
  • (3)Leader服务器为每个Follower服务器分配一个单独的队列,然后将需要广播的 Proposal依次放到队列中去,并且根据FIFO策略进行消息发送。
  • (4)Follower接收到Proposal后,会首先将其以事务日志的方式写入本地磁盘中,写入成功后向Leader反馈一个Ack响应消息。
  • (5)Leader接收到超过半数以上Follower的Ack响应消息后,即认为消息发送成功,可以发送commit消息。
  • (6)Leader向所有Follower广播commit消息,同时自身也会完成事务提交。Follower 接收到commit消息后,会将上一条事务提交。
  • (7)Zookeeper采用Zab协议的核心,就是只要有一台服务器提交了Proposal,就要确保所有的服务器最终都能正确提交Proposal。

ZAB协议针对事务请求的处理过程类似于一个两阶段提交过程

  • (1)广播事务阶段
  • (2)广播提交操作

这两阶段提交模型,有可能因为 Leader 宕机带来数据不一致,比如

  • (1) Leader 发 起 一 个 事 务 Proposal1 后 就 宕 机 , Follower 都 没 有 Proposal1
  • (2)Leader 收到半数 ACK 宕 机,没来得及向 Follower 发送Commit

2、崩溃恢复

崩溃恢复:假设出现异常

假设两种服务器异常情况:

  • (1)假设一个事务在 Leader 提出之后,Leader挂了。
  • (2)一个事务在Leader上提交了,并且过半的Follower都响应Ack了,但是Leader在Commit消息发出之前挂了。

一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半 Follower的联系,那么就会进入崩溃恢复模式。 Zab协议崩溃恢复要求满足以下两个要求:

  • 确保已经被 Leader 提交的提案 Proposal,必须最终被所有的Follower服务器提交。 (已经产生的提案,Follower必须执行)
  • 确保丢弃已经被Leader提出的,但是没有被提交的Proposal。(丢弃胎死腹中的提案)
崩溃恢复: Leader选举
  • 崩溃恢复主要包括两部分:Leader选举和数据恢复。


根据上述要求,Zab 协议 需要保证选举出来的 Leader 需要满足以下条件:

  • 新选举出来的 Leader 不能包含未提交的 Proposal。即新Leader必须都是已经提交了 Proposal 的 Follower 服务器节点。
  • 新选举的 Leader 节点中含有最大的 zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。
崩溃恢复: 数据恢复

Zab如何数据同步:

  • (1)完成Leader选举后,在正式开始工作之前(接收事务请求,然后提出新的Proposal),Leader服务器会首先确认事务日志中的所有的Proposal 是否已经被集群中过半的服务器Commit。
  • (2)Leader服务器需要确保所有的 Follower 服务器能够接收到每一条事务的Proposal,并且能将所有已经提交的事务Proposal应用到内存数据中。 等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过,并且应用到内存数据中以后,Leader 才会把该 Follower 加入到真正可用的 Follower 列表中

3、CAP

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

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

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

1)一致性(C:Consistency)

在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。

2)可用性(A:Available)

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。

3)分区容错性(P:Partition Tolerance)

分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

ZooKeeper 保证的是 CP

  • (1)ZooKeeper 不能保证每次服务请求的可用性。(注:在极端环境下,ZooKeeper 可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper 不能保证服务可用性。

  • (2)进行 Leader 选举时集群都是不可用。

参考文章:
https://blog.csdn.net/qq_41211642/article/details/125965974

https://blog.csdn.net/qq_43752469/article/details/121885818

https://baijiahao.baidu.com/s?id=1698388165171516985

https://blog.csdn.net/Mr_tianyanxiaobai/article/details/121461001

https://www.cnblogs.com/supportmyself/p/15159136.html

你可能感兴趣的:(Zookeeper数据一致性底层算法分析)