Basic-Paxos协议日志同步应用

使用Basic-Paxos协议的日志同步与恢复

传统数据库保持服务持续可用通常采用1主N备, 既采取两种日志同步模式: Maximum Availability和Maximum Protection.

Maximum Availability 表示Primary尽力将redo同步到Standby之后返回client成功, 如果Standby宕机或者网络中断, 那么Primary将单独提供服务, 这意味着Primary单点运行, 或者在Primary故障的情况下, Standby将会出现redo gap, 可能发生数据丢失;
Maximum Protection 表示Primary一定将redo同步到Standby之后返回client成功, 这意味着任何Standby宕机活着网络中断的情况下Primary不得不等待Standby响应活着网络恢复;

很显然在传统的数据安全模式中, A和C很难取舍.

基于Paxos协议的数据同步与传统主备方式最大的区别在与Paxos只需任意超过半数的副本在线且相互通信正常, 就可以保证服务的持续可用, 且数据不丢失.

数据持久化需求:

在N个server的机群里, 持久化数据库或者文件系统的操作日志, 并且为每条日志分配连续递增的logID

允许多个客户端并发的向机群里的任意机器发送日志同步请求

在N个server中只要有超过半数的server(majority)正常服务, 并且相互通信正常, 那么这个机器就可以持续的提供日志持久化和查询服务

先回忆下Basic-Paxos的两个阶段:

第一阶段Prepare:

P1a. proposer发送提案请求

proposer生成一个全局唯一且递增的提案ID(n), 并且向集群内所有acceptor发送prepareRequest(这里无需携带提案内容, 只需要携带提案ID)

P1b. acceptor应答提案请求

acceptor会做出两个承诺, 一个应答.

两个承诺:

承诺不再应答提案ID<=n的prepareRequest

承诺不再应答提案ID<n的acceptRequest

一个应答:

返回acceptor已经应答的提案中提案ID最大的提案.

第二阶段Accept:

P2a. proposer发送提案应答

如果proposer接收到了集群中大多数acceptor响应的prepareRequest(ID=n), 那么proposer可以向集群内的所有acceptor发送acceptRequest(提案ID为n, 提案内容为v), 提案内容可以是提案中被接受的提案ID最大的提案内容, 或者自己可以随意决定提案内容.

P2b. acceptor应答提案应答

如果acceptor接收到提案ID为n的acceptRequest, 除非accepter已经应答了提案ID>n的acceptRequest, 否则accepter将会应答该提案应答.

将每条日志的持久化流程都看作一个

Paxos Instance

, 不同的logID代表不同的

Paxos Instance

形成的"决议(decision)". 即每一个logID标识着一轮完整paxos协议流程的执行, 最后形成decision. 机群内的每个server同时作为paxos的acceptor和proposer.

LogID

proposer get所有acceptor本地目前已写盘的maxlogID, 而只需收集到majority返回的结果, 并选择其中最大的logID+1作为proposer本次待持久化日志的logID.

这里并不能保证并发提交的两条日志一定被分配到不同的logID, 而需要依靠后续的paxos协议流程来达到对一个logID形成唯一的决议(decision)的目的.

ProposalID

获取LogID后, server作为proposer开始针对当前logID, 执行Paxos Instance, 先产生proposalID, 根据paxos协议的要求, proposalID要满足全局唯一且递增序, 即对同一个server来说后产生的proposalID一定大于之前产生的.

Prepare阶段

proposer准备好proposalID后, 将proposalID作为"提案(proposal)"发送给所有的acceptor.

根据Paxos协议P1b的约束, 这个阶段发送的proposal并不需要携带日志内容, 而只需要发送proposalID. acceptor收到proposal后, 根据Paxos协议P1b判断是否要"回应(response)", 只有在这个

Paxos Instance

内(即针对这个logID)没有response过proposalID大于等于当前proposal的, 并且也没有"接受(accept)"过proposalID大于当前proposal的, 才可以response, 并承诺不再accept那些proposalID小于当前proposal的.

如果已经accept过proposal, 那么连同proposalID最大(上次accept的提案)的日志内容一同response. 为了遵守P1b的约束, 在宕机恢复后也能满足, 因此在response前, 需要将当前proposalID写到本地磁盘.

上述Prepare阶段的处理流程暗示, 对于分配到相同logID的不同日志, 由于他们的proposalID不同, acceptor在response一个较小proposalID后, 是允许继续response后来的较大的proposalID的.

Accept请求阶段

proposer收集到majority的response后, 来决定后续是否将要发出的"accept请求(acceptRequest)", 判断如果majority的response中的日志内容都为空, 那么可以向所有acceptor发出acceptRequest并携带上当前日志内容; 而如果有任意的response中的日志内容有效, 那么说明当前logID已经被其他日志占用, 且其他日志可能已经在majority上持久化, 因此需要回退, 回到第一步"获取logID"重新执行.

Accept处理阶段

acceptor收到proposer的acceptRequest后, 根据上文中"Prepare阶段"的承诺, 判断当前logID下, 曾经response过的最大proposalID, 如果小于等于当前proposal的, 则可以继续执行后续的accept处理逻辑; 而如果大于当前proposal的, 则说明有logID且proposalID更大的proposal在并发执行, 当前proposal会被覆盖, 因此回复proposer要求回退到第一步"获取logID"重新执行.

然后accept处理逻辑将当前proposal连同proposalID一起写到本地磁盘, 给proposer回复成功. proposer收集到majority的回复成功后, 说明本条日志已经在机群上持久化成功, 可以保证后续一定不会被覆盖或丢失, 可以给客户端返回成功.

上述accept处理阶段的流程暗示, 可能会存在针对一个logID, 日志只在少于半数的acceptor上写到本地磁盘, 而acceptor同时response了proposalID更大的proposal, 而使得当前logID下没有任何日志在机群上持久化成功. 即一个logID可能没有标识任何有效日志, 这种情况是可以接受的.

日志内容读取

已经在机群上持久化成功的日志, 需要能够被读取出来, 一般的应用模式是按照logID的顺序依次读取并回放日志. 读取的时候针对每一条logID, 需要执行一轮完整的paxos协议流程, 将accept处理阶段成功的日志内容返回.

需要注意的是, 在accept请求阶段的处理逻辑变化: proposer收集到majority的response后, 判断如果majority的response中的日志内容都为空, 那么向所有acceptor发出日志内容为空的acceptRequest; 而如果有任意的response中的日志内容有效, 则选择proposalID最大的日志内容放入acceptRequest. 后续收到majority的accept回复成功后, 才可以返回日志内容作为读取结果.

这里的流程暗示, 针对一个logID, 如果之前已经有日志内容持久化成功, 那么这条日志一定会被选为acceptRequest; 而如果之前日志内容仅仅在小于半数的server上写到磁盘, 那么最终这条logID的内容有可能是有效日志, 也有可能内容为空.

参考: http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf http://www.cs.cmu.edu/~pavlo/courses/fall2013/static/papers/p398-chandra.pdf http://codemacro.com/2014/10/15/explain-poxos/ http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=403582309&idx=1&sn=80c006f4e84a8af35dc8e9654f018ace&3rd=MzA3MDU4NTYzMw==&scene=6#rd http://oceanbase.org.cn/?p=90 http://mp.weixin.qq.com/s?__biz=MjM5MDg2NjIyMA==&mid=203607654&idx=1&sn=bfe71374fbca7ec5adf31bd3500ab95a&key=8ea74966bf01cfb6684dc066454e04bb5194d780db67f87b55480b52800238c2dfae323218ee8645f0c094e607ea7e6f&ascene=1&uin=MjA1MDk3Njk1&devicetype=webwx&version=70000001&pass_ticket=2ivcW%2FcENyzkz%2FGjIaPDdMzzf%2Bberd36%2FR3FYecikmo%3D http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/chubby-osdi06.pdf[/code]