从Paxos到zookeeper分布式一致性原理与实践-Zookeeper与Paxos

Posted 2021-04-13 咖啡日记本

从Paxos到zookeeper分布式一致性原理与实践

Zookeeper与Paxos

Apache Zookeeper是有Apache Hadoop的子项目发展而来,于2010年11月正式成为了Apache顶级项目.Zookeeper为分布式应用提供了高效且可靠的分布式协调服务, 提供了诸如统一命名服务,配制管理和分布式锁的基础服务,在解决分布式一致性方面,Zookeeper并没有直接采用Paxos算法,而是采用了一种被称为ZAB(Zookeeper Atomic Broadcast)的一致性协议.

初识Zookeeper

Zookeeper是什么

Zookeeper是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如数据的发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,Master选举,分布式锁和分布式队列等功能.Zookeeper可以保证如下分布式一致性的特性:

顺序一致性

从同一个客户端发起的事务请求,最终将会严格地按照其发起的顺序被应用到Zookeeper中去.

原子性

所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群所有机器都成功应用了某一个事务, 要么就都没应用.

单一视图

无论客户端连接时哪个Zookeeper服务器,其看到的服务端数据模型都是一致的.

可靠性

一旦服务端成功地应用了一个事务,并完成对客户端的响应,name该事务所引起的服务端状态变更将会一直被保留下来,除非有另一个事务又对其进行了变更.

实时性

Zookeeper仅仅保证在一定的时间内,客户端最终一定能够从服务端上读取到最新数据.

Zookeeper的设计目标

目标一: 简单的数据模型

Zookeeper使得分布式程序能够通过一个共享的,树型结构的名字空间进行互相协调,这里所说的树型结构的名字空间就是Zookeeper的数据模型,被称为Znode,Zookeeper的数据模型类似一个文件系统,Znode之间层级就像文件系统中目录结构一样,Zookeeper将全量数据存储在内存中,以此来实现提高服务器吞吐,减少延迟的目的

目标二: 可以构建集群

Zookeeper提供集群机制,一般3~5台机器就可以组成一个可用的Zookeeper集群了.


组成Zookeeper集群的每台机器都会在内存中维护当前服务器状态,并且每台服机器之间保持通信,Zookeeper集群遵循过半规则, 只要集群中超过一半的机器正常工作,那么整个集群就能够正常对外提供服务.

Zookeeper的客户端会选择和集群中任意一台机器共同创建一个TCP连接,而一旦这个连接意外断开后,客户端会自动连接到集群中的其他机器.

目标三: 顺序访问

对于来自客户端的每个更新请求,Zookeeper都会分配一个全局唯一的递增编号.这个编号反映了所有事物操作的先后顺序,应用程序可以使用Zookeeper的这个特性来实现更高层次的同步原语.

目标四: 高性能

由于Zookeeper将全量数据存储在内存中,并直接服务于客户端所有非事务请求,因此它尤其适合以读操作为主的应用场景.

Zookeeper的基本概念

集群角色

Zookeeper中没有传统集群中Master,Slave概念, 而是引入了Leader,Follwer,Observer三种角色,集群中所有机器通过Leader选举来选定一台被称为Leader的机器,Leader机器为客户端提供读和写服务.除Leader外,其他机器包括Follwer和Observer,二者都提供读服务,唯一区别在于Observer不参与选举也不参与写操作的过半写成功策略,Observer在不影响写性能的情况下提升集群的读性能

会话(session)

Session是指客户端会话,在Zookeeper中,客户端通过TCP长连接通信,客户端能够通过心跳检测与服务器保持有效的会话,也能够向Zookeeper服务器发送请求并接受响应,同时还能通过该连接接收来自服务器的Watch事件通知.Session的sessionTimeout值来设置一个客户端会话超时时间, 当服务器压力太大,连接断开时,只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器,name会话仍然有效

数据节点(Znode)

Zookeeper的节点不同于传统集群节点(一台机器)概念,Zookeeper节点分为两类,第一类是指构建集群的机器,称之为机器节点,第二类是指数据模型中的数据单元,称之为数据节点(Znode),Zookeeper将所有的数据村粗在内存中,数据模型是一棵树(Znode Tree),由斜杠(/)进行分割路径,就是一个Znode,例如/zookeeper/path1.每个Znode上都会保存自己的数据内容(元数据)和一些属性信息.

Zookeeper中的数据节点分为临时节点和持久节点两类.

• 持久节点就是一旦这个Znode被创建了,只要不是主动移除,这个节点会一直保存在Zookeeper上.

• 临时节点是指在绑定在客户端会话上,一旦客户端会话失效,则节点就会被移除.

另外Zookeeper还允许用户为每个节点添加一个特殊属性SEQUENTIAL,一旦节点标记了这个属性,那么节点创建时候会自动在节点名后面追加一个整形数字.

版本

Zookeeper会为每个Znode都维护一个叫做Stat的数据结构,Stat中记录了这个Znode的三个数据版本,分别为version(当前Znode版本),cversion(当前ZNode子节点的版本)和`aversion(当前Znode的ACL版本)

Watcher

Watcher(事件监听器)是Zookeeper中的一个重要特性.Zookeeper允许用户在指定节点上注册一些Watcher,并在触发时通知到感兴趣的客户端上去,该机制是Zookeeper实现分布式协调服务的重要特性.

ACL

Zookeeper采用ACL(Access Control Lists)策略来进行权限控制,类似于UNIX文件系统权限控制,Zookeeper定义了5种权限.

• CREATE: 创建子节点的权限

• READ: 获取节点数据和子节点列表的权限

• WRITE: 更新节点数据的权限

• DELETE: 删除子节点的权限

• ADMIN: 设置节点ACL的权限

Zookeeper的ZAB协议

ZAB协议

ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议.它是一种特别为Zookeeper设计的崩溃可恢复的源自消息广播算法.
ZAB协议的核心是定义了对于那些会改变Zookeeper服务器状态的事务请求的处理方式.即:

所有事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器被称为Leader服务器,而余下
的其他服务器则成为Follower服务器.Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议),
并将该Proposal分发给集群中所有的Follower服务器.之后Leader服务器需要等待所有Follower
服务器的反馈,一旦超过半数的Follower服务器进行正确的反馈后,那么Leader就会再次向所有的
Follower服务器分发Commit消息,要求其将前一个Proposal进行提交.

协议介绍 

ZAB协议包括两种基本模式,分别是崩溃恢复和消息广播.

当整个服务框架在启动过程中,或是Leader服务器出现网络中断,崩溃退出与重启等异常情况时,ZAB协议就会进入恢复模式并选举新的Leader服务器.当选举产生了新的Leader服务器,同事集群中已经有过半的机器与该Leader服务器完成了状态同步之后,ZAB协议就会退出恢复模式.

当集群中已经有过半的Follower服务器完成了和Leader服务器状态同步,那么整个服务框架就进入了消息广播模式了.

消息广播

ZAB协议的消息广播过程使用的是一个原子广播协议,类似于一个二阶段提交过程.针对客户端的事务请求,Leader服务器会为其生成对应的事务Proposal,并将其发送给集群中其余所有的机器,然后再分别收集各自的选票,最后进行事务提交


崩溃恢复

一旦Leader服务器出现崩溃,或者由于网络的原因导致Leader服务器失去过半的Follower的联系,那么就会进入崩溃恢复模式,因此,ZAB协议需要一个高效且可靠的Leader选举算法从而保证能够快速选举出新的Leader,同时要让Leader自己和集群中所有其他的机器能够感知到选举产生的心Leader服务器.

基本特性

• ZAB协议需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交
  
  崩溃恢复过程需要确保已经被Leader提交的Proposal也能够被所有Follower提交

  

• ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务
  
  崩溃恢复过程需要跳过那些已经被丢弃的事务Proposal

数据同步

Leader服务器需要确保所有的Follower服务器能够收到每一条事务Proposal,并能够正确地将所有已经提交了的事务Proposal应用到内存数据库中去.Leader服务器会为每一个Follower服务器准备一个队列,并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器,并在每一个Proposal消息后面紧接着再发送一个Commit消息,以表示该事务已经被提交.等到Follower服务器将所有尚未同步的事务Proposal都从Leader服务器上同步过来并成功应用到本地数据后,Leader服务器就会将该Follower服务器加入到真正可用Follower列表中并开始之后的流程.

在ZXID设计中,ZXID是一个64位的数字,其中低32位可以看做一个单调递增计数器,Leader服务器产生一个新的事务Proposal时候,都会对其进行加1操作,高32位代表了Leader周期epoch的编号,每当选举产生一个新的Leader服务器,就会从这个Leader服务器上读取出本地日志中最大事务Proposal的ZXID,并从ZXID中解析出对应的epoch值,然后进行加1操作.之后就会以此编号作为新的epoch,并将低32位置0来开始生成新的ZXID.

深入ZAB协议

系统模型

ZAB协议需要构建的分布式系统模型，通常在一个由一组进程N={P1,P2,P3....Pn}组成的分布式系统中，其中每一个进程都具有各自的存储设备，各个进程之间通过相互通信来实现消息的传递

一个进程正常状态称为UP状态。如果一个进程崩溃了，我们成为DOWN状态。

事实上当集群中存在过半的处于UP状态的进程组成了一个进程子集之后，就可以进行正常的消息广播。我们将这样的一个进程子集称为Quorum(下文中使用Q来表示)

一个ZK集群必须满足：Q属于N的子集。Q1和Q2两个子集的交集不是空。


我们使用Pi和Pj来分别表示进程集合N中的两个不同进程，使用Cij来表示进程Pi和Pj之间的网络通信通道，其满足如下两个基本特性:

完整性(Integrity)

进程Pj如果收到来自进程Pi的消息m,那么进程Pi一定确实发送了消息m

前置性(Prefix)

如果进程Pj收到了消息m,那么存在这样的消息m',如果m'是m的前置消息,那么Pj务必先接收到消息m',然
后再接收到消息m,我们将存在这种前置性的两个消息表示为: m'<m,前置性是整个协议设计中最关键的一
点,由于每个消息都有可能是基于之前的消息来进行的,因此所有的消息都必须按照严格的先后顺序来进行
处理

算法描述

整个ZAB协议主要包括发现(Discovery),同步(Synchronization),广播(Broadcast)三个阶段.组成ZAB协的没一个分布式进程,会循环地执行这三个阶段,没一个循环称为一个准进程周期

ZAB协议算法表述术语介绍


阶段一: 发现

阶段一主要是Leader选举过程,用于在多个分布式进程中选举出主进程.准Leader L 和Follower F的工作流程分别如下:

阶段二: 同步

在完成发现流程后,就进入了同步阶段,在这一阶段中,Leader L和Follower F的工作流程分别如下:



阶段三: 广播

完成同步阶段之后,ZAB协议就可以正式开始接收客户端新的事务请求,并进行消息广播流程.



ZAB协议算法描述示意图

运行分析

在ZAB协议的设计中,每一个进程都有可能处于一下三种状态之一:

• LOOKING: Leader选举阶段

• FOLLOWING: Follower服务器和Leader保持同步状态

• LEADING: Leader服务器作为主进程领导状态

ZAB与Paxos算法的联系与区别

ZAB协议并不是Paxos算法的典型实现, 在讲解ZAB和Paxos之间的区别之间,先看下两者联系:

• 两者都存在一个类似于Leader进程的角色,由其负责协调多个Follower进程运行

• Leader进程都会等待超半数的Follower做出正确的反馈后,才会讲一个提案进行提交

• 在ZAB协议中,每个Proposal都包含了一个epoch值,用来代表当前的Leader周期,在Paxos算法中,同样存在这样的标识,只是名字变成了Ballot.

两者在本质上的区别在于,两者的设计目标不太一样,ZAB协议主要用于构建一个高可用的分布式数据主备系统,例如Zookeeper,而Paxos算法则是用于构建一个分布式的一致性状态机系统.