zk分布式实现理论,Paxos算法,ZAB协议,CAP定理

集群操作如何保证数据一致 拜占庭将军问题:拜占庭将军问题是一个协议问题,拜占庭帝国…

集群操作如何保证数据一致

拜占庭将军问题:拜占庭将军问题是一个协议问题,拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的,并且将 军中存在叛徒。叛徒可以任意行动以达到以下目标:欺骗某些将军采取进攻行动;促成一个不是所有将军都同意的决定,如当将军们不希望进攻时促成进攻 行动;或者迷惑某些将军,使他们无法做出决定。如果叛徒达到了这些目的之一,则任何攻击行动的结果都是注定要失败的,只有完全达成一致的努力才能 获得胜利。

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

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

在一个Paxos系统中,首先将所有节点划分为Proposer(提议者),Acceptor(接受者),和 Learner(学习者)。(注意:每个节点都可以身兼数职)

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

• Prepare准备阶段 • Proposer向多个Acceptor发出Propose请求Promise(承诺) • Acceptor针对收到的Propose请求进行Promise(承诺)

• Accept接受阶段 • Proposer收到多数Acceptor承诺的Promise后,向Acceptor发出Propose请求 • Acceptor针对收到的Propose请求进行Accept处理

• Learn学习阶段:Proposer将形成的决议发送给所有Learner

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。

案例讲解

有ABCDE五人对公司问题进行决议

第一种情况:

A对其他人发起提议,问能不能接受自己的意见,没说具体内容

BCDE回应A表示同意

A在收到2份回复时就会告知其他人自己提议的具体内容

BCDE在回应A表示同意

此时A的提议就会通过

第二种情况:

A与E同时发起提议,问能不能接受自己的意见,没说具体内容,AE的序号分别为1,2

B回应A,D回应E,这时C成为关键

(1)C先收到A的消息,回应A

此时A就会表明具体意见

BC接受

之后C又收到E的消息,回应E

此时E也会表明具体意见

CD接受

这个时候AE会同时广播决议,因为E的id大,所以E会覆盖A的提议

第三种情况:

AE发起提议

B回应A,D回应E,这时C成为关键

C收到A的消息回复A,这时立刻收到E的消息,又回复E

这时A表明具体意见,C不会回复,没有足够响应

这时候A会从新发起提议,此时A的id会变为3,C又回复A

此时E表明具体意见,C不会回复,又会重新发起提议

这时候就会出现问题

ZAB协议

借鉴了Paxos算法,在Paxos基础上,zookeeper设计只有一台客户端(Leader)负责处理外部写事务的请求,在同步到其他节点,即只有一个Leader可以发起提案

消息广播

(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。

此时会出现2种情况

( 1 ) Leader 发 起 一 个 事 务 Proposal1 后 就 宕 机 , Follower 都 没 有 Proposal1

(2)Leader收到半数ACK宕机, 没来得及向Follower发送Commit

崩溃恢复

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

(1)新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点。

(2)新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。

选举过后,Zab如何数据同步:

(1)完成Leader选举后,在正式开始工作之前(接收事务请求,然后提出新的Proposal),Leader服务器会首先确认事务日 志中的所有的Proposal 是否已经被集群中过半的服务器Commit。

(2)Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal,并且能将所有已经提交的事务Proposal 应用到内存数据中。等到Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过,并且应用到内存数据中以后, Leader才会把该Follower加入到真正可用的Follower列表中。

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选举时集群都是不可用

持久化

Leader与Follower数据会在内存和磁盘各保存一份,所以需要持久化到磁盘中

磁盘会先进行快照存储,等空闲时在同步到磁盘,根据序列化反序列存储信息

初始化过程

本文来自网络,不代表软粉网立场,转载请注明出处:https://www.rfff.net/p/4974.html

作者: HUI

发表评论

您的电子邮箱地址不会被公开。

返回顶部