ZoomKeeper

ZoomKeeper

 

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

 

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

 

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

 

ZooKeeper guarantees

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

 

 

 

ZooKeeper Implementation

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

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

 

Request Processor

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

 

Atomic Broadcast（ZAB原子广播协议）

所有客户端的请求都会先发送给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服务器。

 

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

 

从ACID到CAP/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最终一致性）

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