网站开发设计运维,一元购网站建设流程图,南昌制作网站的公司吗,网站 数据库 sql 导入Zookeeper
ZAB协议
概述
ZAB(Zookeeper Automic Broadcast)是一套专门为Zookeeper设计的用于进行原子广播和崩溃恢复的协议ZAB协议主要包含了两个功能 原子广播#xff1a;保证数据一致性崩溃恢复#xff1a;保证集群的高可用 ZAB协议本身是基于2PC算法来进行的设计#…Zookeeper
ZAB协议
概述
ZAB(Zookeeper Automic Broadcast)是一套专门为Zookeeper设计的用于进行原子广播和崩溃恢复的协议ZAB协议主要包含了两个功能 原子广播保证数据一致性崩溃恢复保证集群的高可用 ZAB协议本身是基于2PC算法来进行的设计加入了PAXOS算法和过半性进行了改进正因为ZAB协议的特点所以Zookeeper是一个CP框架
2PC算法 2PC(Two Phase Commit)二阶段提交顾名思义将请求的完成过程拆分成了2个阶段 在2PC算法中包含了两类角色协调者(negotiator)和参与者(participants) 过程 请求阶段协调者收到请求之后不会立即决定这个请求是否执行而是会将这个请求发送给所有的参与者要求所有的参与者在规定时间内进行反馈 提交阶段当协调者在规定时间内收到所有参与者返回的yes那么就表示这个请求可以执行此时协调者命令所有的参与者执行这个请求 中止阶段当协调者没有在规定时间内收到所有参与者的yes那么此时协调者就会放弃这个请求并且命令所有的参与者也放弃这个请求 2PC只会执行两个阶段请求-提交请求-中止 2PC的核心思想是一票否决 2PC的优势和劣势都非常明显 优势理解和实现过程都会非常简单劣势会非常受外部环境影响。当集群规模较大的时候2PC基本不可能成功 2PC提供了一种思路在分布式环境中如何就一个请求达成所有节点的一致性
PAXOS算法
PAXOS算法是兰伯特在1998年发表的一篇论文PAXOS Made Simple首次提出后来兰伯特在2001年的时候才发表了这个算法的推论过程并且兰伯特凭此获得了图灵奖故事背景在一个PAXOS小岛上生活着一群人这群人由议会管理议会中的每一个议员都不是专职的而是兼职的这也就意味着每一位议员都会随时参与议会提案的决策也随时都会撤离。那么此时如何就一项提案达成一个一致性的意见PAXOS算法解决的问题如何在不稳定网络中达成集群的一致性PAXOS算法中包含了3类角色 Proposer提议者负责提出提案(Proposal)Acceptor接受者接收并且回应提案Learner学习者不参与决策而是学习最后的效果 一个节点既可以是Proposer也可以是Acceptor这与zookeeper不同zookeeper只能有一个leaderPAXOS算法过程 Prepare(准备)阶段 Proposer会先给自己的提案生成一个全局唯一且递增的编号Proposal ID并且给Acceptor发送Propose请求。注意此时这个请求中没有携带具体的请求内容只是携带Proposal IDAcceptor接收到Proposer的请求之后会进行Promise(承诺) 不再接收Proposal ID小于等于当前编号的Propose请求不再接收Proposal ID小于当前提案的Accept请求在不违背承诺的前提下Acceptor回复给Proposer当前接收到的最大的Proposal ID如果没有则返回null Accept(接受/表决阶段 Proposer在接收到半数及以上的Acceptor返回的Promise之后会要求所有的Acceptor执行刚才的提案Acceptor在不违背承诺的前提下会处理这个Proposal Learn(学习)阶段Proposal执行完成之后Learner会执行这个请求 PAXOS算法可能会导致产生活锁
原子广播 原子广播依赖于ZAB协议来实现了数据一致性。基于ZAB协议Zookeeper实现了一种类似于主从结构的特点 不同于PAXOS算法的地方在于在ZAB协议中只允许一个角色(leader)进行提案并且在集群中只能有一个leader(全局唯一)从而避免产生活锁问题 过程 leader接收到请求之后会先将这个请求记录到本地的日志文件中如果记录成功那么leader会为这个请求生成一个唯一的编号(事务idZxid)然后将Zxid放到队列中发送给每一个followerfollower收到队列之后会从队列中依次取出请求记录到本地的日志文件中。如果记录成功那么会给leader返回一个ACK(Acknowledge Character确认字符)表示确认如果记录失败那么会给leader返回一个失败信息如果leader收到半数及以上的follower返回的ACK那么就表示这个请求可以执行那么此时leader就会命令所有的follower以及observer执行这个请求反之就会命令所有的follower以及observer放弃这个请求 日志文件的位置由dataLogDir属性决定但是dataLogDir的值默认和dataDir一致 查看log文件 # 从Zookeeper3.5.5开始提供了zkTxnLogToolkit.sh在3.5.5之前通过LogFormatter类来查看
zkTxnLogToolkit.sh log.200000001查看快照文件 zkSnapShotToolkit.sh snapshot.100000000如果follower记录失败那么还需要执行这个请求此时follower会给leader发送请求请求获取刚才任务的事务id重新记录记录成功则执行这个任务如果记录失败那么会重新请求重新记录 如果一个节点加入了Zookeeper这个节点会先找到自己最大的事务id然后自己的最大事务id发送给leaderleader收到之后会将欠缺的事务放入队列中发送给这个followerfollower收到之后回依次从队列中取出请求依次记录执行。这个节点在补齐期间不对外接收写操作 注意Zookeeper所有的节点都能接收请求如果是读请求那么直接处理回复如果follower接收到了写请求会将这个请求转给leader进行原子广播
扩展
CAP理论
概述
对于分布式框架而言基本上都会遵循CAP三大理论CAP(CAP理论是从客户端角度出发的) C(Consistency)一致性。在一段时间内访问这个集群获取到的数据是相同的 。注意此时在一个时间段内不要求每一台服务器的数据都一样只要保证客户端获取到的数据一样就行A(Availability)可用性。当客户端对集群中的节点发起请求的时候节点能够在合理的时间内(一般理解为立刻)进行响应 - 时效性。注意此处的可用性和服务器的高可用不是一回事儿P(Partition Tolerance)分区容忍性。当集群中的某一个或者一部分节点产生故障的时候不会影响集群其他功能的使用和运行。注意服务器的高可用指的是分区容忍性 CAP经过严格的理论证明无法同时满足。对于集群而言首先要考虑满足P所以一个集群要么是CP结构要么是AP结构
一致性方式
强一致性当一个节点上的数据发生变化的时候其他节点能够立即感知这个变化并作出对应相应弱一致性当一个节点上的数据发生变化的时候其他节点能够部分感知这个变化或者对变化没有感知最终一致性忽略中间过程最终结果相同
一致性实现方案
主从(Master-Slave简称为M/S)结构通过一个主节点来管理其他的从节点客户端只能通过访问主节点来获取数据PAXOS算法及其变种例如ZAB协议就是PAXOS的变种算法WNR策略。W表示写入节点数量R表示读取节点数量N表示总节点数量只要保证WRN就能保证数据一致性——
