<从PAXOS到ZOOKEEPER分布式一致性原理与实践>读书笔记-paxos算法

本文属于分布式系统学习笔记系列,上一篇笔记梳理了2阶段、3阶段提交。本文来梳理paxos算法。

背景:

本书第二章里面作者详细介绍了paxos算法的由来,这里从2.2.3开始。

Paxos算法实现的是分布式系统多个结点之上数据的一致性,这个算法有如下特性

1.基于消息传递,允许消息传输的丢失,重复,乱序,但是不允许消息被攥改

2.在结点数少于半数失效的情况下仍然能正常的工作,结点失效可以在任何时候发生而不影响算法正常执行。

paxos算法

算法中的参与者主要分为三个角色,同时每个参与者又可兼领多个角色:

⑴proposer 提出提案,提案信息包括提案编号和提议的value;

⑵acceptor 收到提案后可以接受(accept)提案;

⑶learner 只能"学习"被批准的提案;

问题描述,一致性算法需要保证:

  • 决议(value)只有在被proposers提出后才能被批准(未经批准的决议称为"提案(proposal)");
  • 在一次Paxos算法的执行实例中,只批准(chosen)一个value;
  • learners只能获得被批准(chosen)的value;

接下来作者介绍了提案的选定及推导过程。

Proposer生成提案:

1.proposer选择一个新的提案编号Mn,然后向某个acceptor 集合的成员发送请求,要求回应如下:
  • 向Proposer承诺,保证不再批准任何编号小于Mn的提案。
  • 如果acceptor 已经审批任何提案,那么其就向Proposer反馈当前acceptor 已经批准的编号小于Mn但为最大编号的那个提案的值。
这个阶段为编号Mn提案的prepare阶段。
2如果Proposer接收到了超过半数的acceptor 响应结果,那么就可以产生编号为,value为Vn的提案。这里的Vn是所有相应中编号最大的提案的value值。当然存在另一种情况,就是超过半数的acceptor 从未审批过任何提案,即响应中不包含任何提案,那么此时Vn值就可以有Proposer任意选择
再确定提案后,Proposer会将该提案再次发给某个acceptor 集合,并期望获得它的批准,此请求称为accept请求。

Acceptor批准提案:

根据上面的内容,acceptor 可能接受到来自Proposer的两种请求:

  • Prepare请求acceptor 可以在任何时候响应一个prepare请求。
  • Accept请求:在不违背accept现有承诺情况下,可以响应任何accept请求。
约束规则如下:P1a,一个Acceptor只要未响应过任何编号大于Mn的Prepare请求,那么它就可以接受编号为Mn的提案。

提案获取:leaner获取提案,三种方式。

通过选取主Proposer保证算法活性

   Paxos算法在出现竞争的情况下,其收敛速度很慢,甚至可能出现活锁的情况,例如当有三个及三个以上的proposer在发送prepare请求后,很难有一个proposer收到半数以上的回复而不断地执行第一阶段的协议。因此,为了避免竞争,加快收敛的速度,在算法中选取主Proposer作为leader,并规定它才能提出议案,而其它的参与者则扮演Acceptor的角色,同时所有的人又都扮演Learner的角色。

这样一来,只要leader和过半的Acceptor能够正常的进行网络通信,那么但凡leader提出一个编号更高的提案,该提案终将会被批准,流程就能保证活性。此时的paxos算法在本质上就退变为两阶段提交协议。但在异常情况下,系统可能会出现多Leader的情况,但这并不会破坏算法对一致性的保证,此时多个Leader都可以提出自己的提案,优化的算法就退化成了原始的paxos算法。

原书本章内容到此结束,补充下优化后的相关知识。

**********************************************************************

一个Leader的工作流程主要有分为三个阶段:

(1).学习阶段 向其它的参与者学习自己不知道的数据(决议);

(2).同步阶段 让绝大多数参与者保持数据(决议)的一致性;

(3).服务阶段 为客户端服务,提议案;

paxos算法理论上学习到此结束了,实际应用结合网上的例子“使用Basic-Paxos协议的日志同步与恢复”去学习。
下一篇继续学习第四章,ZAB算法。


阅读更多
文章标签: paxos
个人分类: 分布式
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭