首页 > 代码库 > 分布式多副本下如何通过日志同步实现副本数量变更

分布式多副本下如何通过日志同步实现副本数量变更

           上一篇博客《RAFT中成员变更过程以及失败回滚分析 》,分析了副本变更的背景知识和RAFT提出的joint consensus的实现方式。可惜的是,RAFT在其论文和博士论文中都没有给出joint consensus的严格证明,我们在实现oceanbase的乱序日志方案时,初期参照RAFT的joint consensus,但总能找到协议漏洞,于是采用 case by case的方式逐步修改协议,直到我们几个人再 也找不到漏洞的时候,还是不能证明方案设计的正确性。

          忘了哪位Google的大神说过“世界上只存在一种一致性协议,那就是PAXOS”,好吧,为了正确性,还是要从伟大的PAXOS出发。于是,和同事讨论后,提出一种可以证明正确性的成员变更实现方案。

          在没有成员变更的情况下,PAXOS决议的的类型只有一种,即某条日志的内容是什么(简称为L<Lid,session>);引入成员变更后,其实PAXOS决议的类型多了一种,我们之前一直没有引起重视,即某条日志的PAXOS group是哪些server(简称为G<Gid,Lid, group >)。显然,在提出(而不是批准)一个L的前,就需要确定L的G信息,这是保证正确性的必要条件。

         如果我们假设外部有一个完全可靠的地方,能够提供可靠的读写服务,保证多次重复读,都能读到一个一致的信息,我们可以把G存储于此,每次在对L进行PAXOS propose的时候,去读取G信息,决定其所属的group。不幸的是,不存在这样的理想存储情况,我们必须利用现有的集群,把G信息存储多份,这又是一个PAXOS过程。

          我们可以构造这样一个系统,满足以下约束:

1.        系统中只有一个leader,在上一条日志没有形成多数派之前,leader不会提出(propose)第二条日志,那么系统中无论发生了什么情况,最多只能有一个未决日志;

2.        系统在写第一条日志前,先写入一个初始配置信息S,指明第一条日志的PAXOS  group 信息;

3.        每条日志除了包含原有日志内容外,还需要指明下一条日志的group信息(仅仅是下一条,而不是下一条到无穷大条),即第i条日志形成多数派后,第i+1条日志的PAXOSgroup 信息就不会变了,此时才可以进入第i + 1条日志的propose阶段。

 

          显然,上述系统是正确的。这个显然,其实还是需要进一步证明。。。

          在假设上述是正确的前提下,如果想实现成员变更,可以在第x条日志中,写入第x+1条的PAXOS group 信息,需要注意的是,此时x+1这条日志的内容是在new  group的,而x+1的PAXOS group 信息是在old group上的,但无论是什么信息,都是满足一致性约束的。

 

        这个系统并发度实在太低了,我们需要给他加速:

1.        系统初始配置信息S,指明了第1条到 第1K条日志的PAXOSgroup 信息;

2.        第1条日志的内容中,记录了第1001条日志的PAXOSgroup 信息,第2条日志的内容中,记录了第1002条日志的PAXOS group信息,也就是说第i 条日志中记录第i + 1K条日志的PAXOS group 信息。

 

         在加速系统中,第1条日志之和第1K + 1条日志有先后关系,而第1条到1K条之间是独立的,是可以多条日志并发进行PAXOS 投票的,这也和我们之前的滑动窗口契合。

          在加速系统中,如果需要做成员变更,假设当前滑动窗口的最右边的日志ID是right,则生成一条成员变更信息,信息内容是:从2K + right开始,日志需要写到新的group上,然后将这个信息写入第right + 1条日志中同步给多数派。第2K + right条日志的PAXOS group 信息是记录在1K  + right日志内容中,因此,在1K + right日志生成(propose)前,第right + 1条日志必须形成多数派,这是一个约束。

          这不同于raft ,必须经历一个joint consensus阶段,只需要一个阶段,即可以完成成员变更。

       具体到实现中,可能还有各种各样的问题,需要进一步细化设计。


分布式多副本下如何通过日志同步实现副本数量变更