ZoomKeeper

ZoomKeeper

 

一个用于协调分布式应用程序的无等待服务。

 

线性化:更改zoomkeeper状态的所有请求

 

Zab:可以保证令人满意的线性化更新操作

 

ZooKeeper guarantees

  • 可线性化写(Linearizable writes):所有更新zoomkeeper状态的请求都是可序列化的❓,并且遵守先后原则。
  • FIFO client order:来自客户端的所有请求都按照客户端发送的顺序执行。

 

 

 

ZooKeeper Implementation

高可用性:通过在服务器间复制数据达到

复制数据库包含复制整个内存数据库树

 

Request Processor

这里的请求处理可能是客户端向leader发送的一个读请求或者写请求。如果leader收到请求后发现这个请求是正确的,就会执行请求中的任务,如果发现请求有错误或者请求的内容不存在就会返回错误。

 

Atomic BroadcastZAB原子广播协议)

所有客户端的请求都会先发送给zoomkeeper中的leader,leader在接收到请求后,通过原子广播协议发送给其他的服务器。ZAB协议只有在大多数节点都能工作的情况下才能生效。

如何保证高吞吐量:保证请求管道始终满。

如何保证原子性:广播按顺序传递,并且保证前一个领导者的广播在后一个leader之前广播。

通过TCP传输

使用日志记录提议,并记录在内存数据库中

 

ZAB是zoomkeeper中的一致性算法实现

 

协议状态:

ZAB协议中存在着三种状态,每个节点都属于以下三种中的一种:

  1. Looking:系统刚启动时或者Leader崩溃后正处于选举状态

  2. Following:Follower节点所处的状态,Follower与Leader处于数据同步阶段;

  3. Leading:Leader所处状态,当前集群中有一个Leader为主进程;

 

ZAB协议定义了选举(election)、发现(discovery)、同步(sync)、广播(Broadcast)四个阶段;

  1. Election:在Looking状态中选举出Leader节点,Leader的lastZXID总是最新的;

  2. Discovery:Follower节点向准Leader推送FOllOWERINFO,该信息中包含了上一周期的epoch,接受准Leader的NEWLEADER指令,检查newEpoch有效性,准Leader要确保Follower的epoch与ZXID小于或等于自身的;

  3. sync:将Follower与Leader的数据进行同步,由Leader发起同步指令,最总保持集群数据的一致性;

  4. Broadcast:Leader广播Proposal与Commit,Follower接受Proposal与Commit;

  5. Recovery:保持数据的一致;

 

选举(Election)
  election阶段必须确保选出的Leader具有highestZXID,否则在Recovery阶段没法保证数据的一致性
选举流程:
  1. 每个Follower都向其他节点发送选自身为Leader的Vote投票请求,等待回复;
  2. Follower接受到的Vote如果比自身的大(ZXID更新)时则投票,并更新自身的Vote,否则拒绝投票;
  3. 每个Follower中维护着一个投票记录表,当某个节点收到过半的投票时,结束投票并把该Follower选为Leader,投票结束;

 

  ZAB协议中使用ZXID作为事务编号,ZXID为64位数字,低32位为一个递增的计数器,每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1,高32位为Leader周期epoch编号,当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch,将低32位从0开始生成新的ZXID;ZAB使用epoch来区分不同的Leader周期;

 

  恢复(Recovery)
  在election阶段选举出来的Leader已经具有最新的ZXID,所有本阶段的主要工作是根据Leader的事务日志对Follower节点数据进行更新;
  

参考:https://blog.csdn.net/jin5203344/article/details/53142027?utm_source=blogxgwz6?utm_medium=distribute.pc_relevant.none-task-blog-baidujs-2

 

ZoomKeeper服务器以FIFO来处理客户端的请求。

 

6 相关工作中提到:

zookeeper允许客户端连接任何ZooKeeper服务器,而不仅仅是leader。ZooKeeper客户端可以使用local replicas来提供数据和管理手表,因为它的一致性模型要比Chubby宽松得多。这使得ZooKeeper能够提供比chubby更高的性能,允许应用程序更广泛地使用ZooKeeper

 

 

ZAB协议

---从PAXOS到ZOOKEEPER分布式一致性原理与实践

ZAB协议是为分布式协调服务Zoomkeeper专门设计的一种支持崩溃恢复的原子广播协议。

 

当Leader服务器出现网络中断、崩溃退出、与重启等异常情况时,ZAB协议就会进入恢复模式并选举产生新的Leader服务器。

 

脑裂:分布式系统中的主机由于网络原因进行分区。

 

ACIDCAP/BASE

 

事务具有的四个特征:ACID

原子性(Atomicity)

一致性(Consistency)

隔离性(Isolation)

持久性(Durability)

 

幻影数据:前后两次读取数据,数据出现不一致的情况。

 

消息广播、崩溃恢复

 

二阶段提交过程

 

 

在消息广播过程中,Leader服务器会为每个事物请求生成对应的Proposal来进行广播,并且在广播之前Leader服务器会首先为这个事物proposal分配全局单调递增的唯一ID,称之为事物ID(即ZXID)。由于ZAB协议需要保证每一个消息严格的因果关系,因此必须将每一个事物Proposal按照其ZXID的先后顺序来进行排序与处理。

 

消息广播具体流程:

在消息广播过程中,Leader服务器会为每一个Follower服务器都各自分配一个单独的队列,然后将需要广播的事务proposal依次放入这些队列中去,并且根据FIFO策略进行消息发送。每一个Follower服务器在接收到这个事物Proposa

l之后,都会首先将其以事物日志的形式写入到本地磁盘中去,并且在成功写入后反馈给Leader服务器一个Ack响应。当Leader服务器接收到超过半数Follower的Ack响应后,就会广播一个Commit消息给所有的Follower服务器以通知其进行事物提交,同时Leader自身也会完成对事物的提交,而每一个Follower服务器在接收到Commit消息后,也会完成对事物的提交。

 

崩溃恢复:

一旦Leader服务器出现崩溃,或者网络原因导致Leader服务器失去了过半Follower的联系,那么就会进入崩溃恢复模式。在ZAB协议中,为了保证程序的正确运行,整个恢复过程后需要选举出一个新的Leader服务器。

 

ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交

 

数据同步:

所有的proposal已经被集群中过半的机器提交

 

4.2.3 深入ZAB协议

 

CAP定理:

CAP最多只能同时满足两项❓

一致性:Consistency

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

 

可用性:Availability

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

 

分区容错性:Partition tolerance

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

 

脏数据:又叫老数据,指的是没有更新的数据。

强一致性(严格一致性):保证用户读取到的值是最新的

 

强一致性和最终一致性:

最终一致性是说数据追踪能够达到一个一致的状态,具体多久能够达到数据一致性取决于系统的设计,主要包括数据副本在不同节点之间的复制时间长短。

 

BASE理论:

核心思想:即使无法达到强一致性(Strong Consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventually consistency)

 

Basically Available(基本可用)

基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性,有以下两种情况:

响应时间上的损失:正常情况下,一个在线搜索引擎需要在0.5s之内返回给用户相应的查询结果,但由于出现故障(比如断网或断网),查询结果的响应时间增加到了1~2s。

 

Soft state(软状态)

指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同的数据副本之间进行数据同步的过程存在延时。

 

Eventually consistent9最终一致性)

指的是系统中所有的数据副本,在经过一段时间的同步后,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

 

 

 

 

 

 

 

 

 

 

 

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页