zookeeper live(二)之2pc与paxos算法
-
2pc(两阶段提交),在分布式系统中,每一个机器节点虽然都能够明确知道自己在事务操作过程中的结果是成功或者失败的,但不会知道其他节点执行成功或者失败,因此事务操作需要跨越多个分布式节点时,需要引入一个协调者统一调度所有节点的执行逻辑
-
阶段一:提交事务请求
-
事务询问
当客户端将事务请求发送给协调者后,协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
-
执行事务
各参与者节点执行事务操作,并将undo和redo信息记入事务日志当中。
-
各参与者
如果参与者成功执行了事务操作,那就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务操作,那就反馈给协调者No响应,表示事务不可以执行。
-
-
阶段二:执行事务提交
在阶段二中,协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作,正常情况下,包含以下两种可能。
执行事务提交
假如协调者从所有的参与者获得的反馈都是Yes响应,那么就会执行事务提交。
-
发送提交请求
协调者向所有参与者节点发送Commit请求。
-
事务提交
参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后,释放在整个事务执行期间占用的事务资源。
-
反馈事务提交结果
参与者在完成事务提交之后,向协调者发送Ack消息。
-
完成事务
协调者接收到所有参与者反馈的Ack消息后,完成事务。
-
-
两阶段提交的图
-
paxos算法
-
组成
Acceptor
proposer
learner
-
两个步骤
-
生成提案
-
Proposer选择一个新的提案编号M,然后向某个Accepter集合的成员发送请求,要求该集合的Acceptor作出如下回应。
-
向Proposer保证,保证不再接受任何编号小于M的提案。
-
如果Acceptor已经批准过任何提案,那么就向Proposer反馈当前该Acceptor已经批准的编号小于M但为最大编号的那个提案的值。
-
-
如果Proposer收到了来自半数以上的Acceptor的响应结果,那么它就可以产生编号为M的提案被接受了;如果半数以上的Acceptor都没有批准过任何提案,即响应中不包含任何提案,那么此时提案就由Proposer自己选择了。
-
-
-