关于im:转载微信自研生产级paxos类库PhxPaxos实现原理介绍

微信重磅开源生产级 paxos 类库 PhxPaxos，本文用科普的口气向大家介绍 PhxPaxos 背地的实现原理以及一些有意思的细节。

前言

本文是一篇无需任何分布式以及 paxos 算法根底的人能够看懂的。

题目次要有三个关键字，生产级，paxos，实现，涵盖了本文的重点。什么叫生产级，直译就是能用于生产线的，而非试验产品。生产级别领有超高的稳定性，不错的性能，能真正服务于用户的。paxos 就不用说了，而实现，是本文最大的重点，本文将避开 paxos 算法实践与证实，直入实现细节，通知大家一个生产级别的 paxos 库背地的样子。为何要写这篇文章？paxos 算法实践与证实不是更重要么？我几年前已经也读过 Paxos 论文，尽管大抵了解了算法的过程，然而在脑海中却无一个场景去构建这个算法，而后也就缓缓印象淡化以至于最近重读 paxos 论文的时候，感觉像是第一次读论文的样子。

在真正去实现了 paxos 之后，我才顿悟了这个问题。人们去了解一个实践或事务的时候，都会往这个实践或事物上套一个场景，而后在脑海里模仿而试图去懂得他。比方经典的 Dijkstra 算法，事实它并不只用于最短寻路，然而在学习这个算法的时候，最短寻路给咱们提供了一个很好的场景，能够让咱们更快的去了解它。

第一次读 paxos 论文，我不晓得它的利用场景，不晓得它是用来干什么的，也不晓得它怎么实现，然而这些往往就是一个根底，大神可能能够本人发明场景，然而更多的人都须要晓得这个场景，当你晓得后，了解算法将变得更为容易。

本文，将通知你 paxos 是什么，用来做什么，怎么应用它，如何工程化，如何做到生产级别，以及在工程上会遇到的问题与解决办法。文中将用尽量讲课形式的口气，以及尽量避免专业术语，力求把这么一件事能论述的更为艰深和简略易懂。

什么是 paxos

一致性协定

Paxos 是一个一致性协定。什么叫一致性？一致性有很多种，也从强到弱分了很多等级，如线性一致性，因果一致性，最终一致性等等。什么是统一？这里举个例子，三台机器，每台机器的磁盘存储为 128 个字节，如果三台机器这 128 个字节数据都完全相同，那么能够说这三台机器是磁盘数据是统一的，更为形象的说，就是多个正本确定同一个值，大家记录下来同一个值，那么就达到了一致性。

Paxos 能达到什么样的一致性级别？这是一个较为简单的问题。因为一致性往往不取决与客观存在的事实，如 3 台机器尽管领有雷同的数据，然而数据的写入是一个过程，有工夫的先后，而更多的一致性取决于观察者，观察者看到的并未是最终的数据。这里就先不开展讲，先暂且认为 paxos 保障了写入的最终一致性。

为何说是一个协定而不是一个算法，能够这么了解，算法是设计进去服务于这个协定的，如同法律是协定，那么算法就是各种机构的执行者，使得法律的束缚能失去保障。

Paxos 的协定其实很简略，就三条规定，我认为这三条规定也是 paxos 最精华的内容，各个执行者奋力的去爱护这个协定，使得这个协定的束缚失效，天然就失去了一致性。

分布式环境

为何要设计出这么一套协定，其余协定不行么。如最容易想到的，一个值 A，往 3 台机器都写一次，这样一套简略的协定，能不能达到一致性的成果？这里就波及到另外一个概念，Paxos 一致性协定是在特定的环境下才须要的，这个特定的环境称为异步通信环境。而恰好，简直所有的分布式环境都是异步通信环境，在计算机领域面对的问题，十分须要 Paxos 来解决。

异步通信环境指的是音讯在网络传输过程中，可能产生失落，提早，乱序景象。在这种环境下，下面提到的三写协定就变得很鸡肋了。音讯乱序是一个十分顽劣的问题，这个问题导致大部分协定在分布式环境下都无奈保障一致性，而导致这个问题的根本原因是网络包无法控制超时，一个网络包能够在网络的各种设施交换机等停留数天，甚至数周之久，而在这段时间内任意收回的一个包，都会跟之前收回的包产生乱序景象。无法控制超时的起因更多是因为时钟的关系，各种设施以及交换机时钟都有可能错乱，无奈判断一个包的真正达到工夫。

异步通信环境并非只有 paxos 能解决一致性问题，经典的两阶段提交也能达到同样的成果，然而分布式环境外面，除了音讯网络传输的顽劣环境，还有另外一个让人痛心疾首的，就是机器的当机，甚至永恒失联。在这种状况下，两阶段提交将无奈实现一个一致性的写入，而 paxos，只有多数派机器存活就能实现写入，并保障一致性。

至此，总结一下 paxos 就是一个在异步通信环境，并容忍在只有多数派机器存活的状况下，依然能实现一个一致性写入的协定。

提议者

后面讲了这么多都是协定协定，在分布式环境当中，协定作用就是每台机器都要表演一个角色，这个角色严格遵守这个协定去解决音讯。在 paxos 论文外面这个角色称之为 Acceptor，这个很好了解。大家其实更关怀另外一个问题，到底谁去发动写入申请，论文外面介绍发动写入申请的角色为提议者，称之为 Proposer，Proposer 也是严格遵守 paxos 协定，通过与各个 Acceptor 的协同工作，去实现一个值的写入。在 paxos 外面，Proposer 和 Acceptor 是最重要的两个角色。

Paxos 是用来干什么的

确定一个值

既然说到写入数据，到底怎么去写？写一次还是写屡次，还是其余？这也是我一开始苦恼的问题，置信很多人都会很苦恼。

这里先要明确一个问题，paxos 到底在为谁服务？更确定来说是到底在为什么数据服务？还是引下面的例子，paxos 就是为这 128 个字节的数据服务，paxos 并不关怀里面有多少个提议者，写入了多少数据，写入的数据是不是一样的，paxos 只会跟你说，我确定了一个值，当这个值被确定之后，也就是这 128 个字节被确定了之后，无论里面写入什么，这个值都不会扭转再扭转了，而且三台机确定的值必定是一样的。

说到这预计必定会有人蒙逼了，说实话我过后也蒙逼了，我要实现一个存储服务啊，我要写入各种各样的数据啊，你给我确定这么一个值，能有啥用？但先抛开这些疑难，大家先要明确这么一个概念，paxos 就是用来确定一个值用的，而且大家这里就先晓得这么个事件就能够了，具体 paxos 协定是怎么的，怎么通过协定外面三条规定来取得这样的成果的，怎么证实的等等实践上的货色，都举荐去大家去看看论文，然而先看完本文再看，会失去另外的成果。

如下图，有三台机器（前面为了简化问题，不做特地阐明都是以三台机器作为解说例子），每台机器上运行这 Acceptor 来恪守 paxos 协定，每台机器的 Acceptor 为本人的一份 Data 数据服务，能够有任意多个 Proposer。当 paxos 协定声称一个值被确定（Chosen）后，那么 Data 数据就会被确定，并且永远不会被扭转。

Proposer 只须要与多数派的 Acceptor 交互，即可实现一个值的确定，但一旦这个值被确定下来后，无论 Proposer 再发动任何值的写入，Data 数据都不会再被批改。Chosen value 即是被确定的值，永远不会被批改。

确定多个值

对咱们来说，确定一个值，并且当一个值确定后是永远不能被批改的，很显著这个利用价值是很低的。尽管我都甚至还不晓得确定一个值能用来干嘛，但如果咱们能有方法能确定很多个值，那必定会比一个值有用得多。咱们先来看下怎么去确定多个值。

上文提到一个三个 Acceptor 和 Proposer 各自恪守 paxos 协定，协同工作最终实现一个值的确定。这里先定义一个概念，Proposer，各个 Acceptor，所服务的 Data 独特形成了一个大的汇合，这个汇合所运行的 paxos 算法最终目标是确定一个值，咱们这里称这个汇合为一个 paxos instance，即一个 paxos 实例。

一个实例能够确定一个值，那么多个实例天然能够确定多个值，很简略的模型就能够构建进去，只有咱们同时运行着多个实例，那么咱们就能实现确定多个值的指标。

这里强调一点，每个实例必须是齐全独立，互不干涉的。意思就是说 Acceptor 不能去批改其余实例的 Data 数据，Proposer 同样也不能逾越实例去与其余实例的 Acceptor 交互。

如下图，三台机器每台机器运行两个实例，每个实例独立运作，最终会产生两个确定的值。这里两个理论能够扩大成任意多个。

至此，实例 (Instance) 以成为了我当初介绍 paxos 的一个根本单元，一个实例确定一个值，多个实例确定多个值，但各个实例独立，互不干涉。

然而比拟遗憾的一点，确定多个值，依然对咱们没有太大的帮忙，因为外面最可恨的一点是，当一个值被确定后，就永远无奈被批改了，这是咱们不能承受的。大部分的存储服务可能都须要有一个批改的性能。

有序的确定多个值

咱们须要转换一下切入点，兴许咱们须要 paxos 确定的值，并不一定是咱们真正看到的数据。咱们察看大部分存储系统，如 LevelDB，都是以 AppendLog 的模式，确定一个操作系列，而后须要复原存储的时候都能够通过这个操作系列来复原，而这个操作系列，正是确定之后就永远不会被批改的。到这曾经很恍然大悟了，只有咱们通过 paxos 实现一个多机统一的有序的操作系列，那么通过这个操作系列的演进，可实现的货色就很有设想空间了，存储服务必然不是问题。

如何利用 paxos 有序的确定多个值？上文咱们晓得能够通过运行多个实例来实现确定多个值，但为了达到程序的成果，须要增强一下束缚。

首先给实例一个编号，定义为 i，i 从 0 开始，只增不减，由本机器生成，不依赖网络。其次，咱们保障一台机器任一时刻只能有一个实例在工作，这时候 Proposer 往该机器的写申请都会被当前工作的实例受理。最初，当编号为 i 的实例获知曾经确定好一个值之后，这个实例将会被销毁，进而产生一个编号为 i + 1 的实例。

基于这三个束缚，每台机器的多个实例都是一个间断递增编号的有序系列，而基于 paxos 的保障，同一个编号的实例，确定的值都是统一的，那么三台机都取得了一个有序的多个值。

上面联合一个图示来具体阐明一下这个运作过程以及存在什么异常情况以及异常情况下的解决形式。

图中 A,B,C 代表三个机器，红色代表曾经被销毁的实例，依据上文束缚，最大的实例就是以后正在工作的实例。A 机器当前工作的实例编号是 6，B 机是 5，而 C 机是 3。为何会呈现这种工作实例不一样的状况？首先解释一下 C 机的状况，因为 paxos 只要求多数派存活即可实现一个值的确定，所以假如 C 呈现当机或者音讯失落提早等，都会使得本人不晓得 3 - 5 编号的实例曾经被确定好值了。而 B 机比 A 机落后一个实例，是因为 B 机刚刚参加实现实例 5 的值的确定，然而他并不知道这个值被确定了。下面的状况与其说是异常情况，也能够说是失常的状况，因为在分布式环境，产生这种事件是很失常的。

上面剖析一下基于图示状态的对于 C 机的写入是如何工作的。C 机实例 3 解决一个新的写入，依据 paxos 协定的保障，因为实例 3 曾经确定好一个值了，所以无论写入什么值，都不会扭转原来的值，所以这时候 C 机实例 3 发动一轮 paxos 算法的时候就能够获知实例 3 真正确定的值，从而跳到实例 4。但在工程实现上这个事件能够更为简化，上文提到，各个实例是独立，互不干涉的，也就是 A 机的实例 6，B 机的实例 5 都不会去理睬 C 机实例 3 收回的音讯，那么 C 机实例 3 这个写入是无奈失去多数派响应的，天然无奈写入胜利。

再剖析一下 A 机的写入，同样实例 6 无奈取得多数派的响应，同样无奈写入胜利。同样如果 B 机实例 5 有写入，也是写入失败的后果，那如何使得能持续写入，实例编号能持续增长呢？这里引出下一个章节。

实例的对齐(Learn)

**
**

上文说到每个实例外面都有一个 Acceptor 的角色，这里再减少一个角色称之为 Learner，顾名思义就是找他人学习，她回去询问别的机器的雷同编号的实例，如果这个实例曾经被销毁了，那阐明值曾经确定好了，间接把这个值拉回来写到以后实例外面，而后编号增长跳到下一个实例再持续询问，如此重复，直到以后实例编号增长到与其余机器统一。

因为束缚外面保障仅当一个实例获知到一个确定的值之后，能力编号增长开始新的实例，那么换句话说，只有编号比当前工作实例小的实例（已销毁的），他的值都是曾经确定好的。所以这些值并不需要再通过 paxos 来确定了，而是间接由 Learner 间接学习失去即可。

如上图，B 机的实例 5 是间接由 Learner 从 A 机学到的，而 C 机的实例 3 - 5 都是从 B 机学到的，这样大家就全副走到了实例 6，这时候实例 6 承受的写申请就能持续工作上来。

如何利用 paxos

状态机

**
**

一个有序的确定的值，也就是日志，能够通过定义日志的语义进行重放的操作，那么这个日志是怎么跟 paxos 联合起来的呢？咱们利用 paxos 确定有序的多个值这个特点，再加上这里引入的一个状态机的概念，联合起来实现一个真正有工程意义的零碎。

状态机这个名词大家都不生疏，一个状态机必然波及到一个状态转移，而 paxos 的每个实例，就是状态转移的输出，因为每台机器的实例编号都是间断有序增长的，而每个实例确定的值是一样的，那么能够保障的是，各台机器的状态机输出是完全一致的。依据状态机的实践，只有初始状态统一，输出统一，那么引出的最终状态也是统一的。而这个状态，是有有限的设想空间，你能够用来实现十分多的货色。

如下图这个例子是一个状态机联合 paxos 实现了一个具备多机统一的 KV 零碎。

实例 0 - 3 的值都曾经被确定，通过这 4 个值最终引出 (b,‘jeremy’) 这个状态，而各台机器实例系列都是统一的，所以大家的状态都一样，尽管引出状态的工夫有先后，但确定的实例系列确定的值引出确定的状态。

下图例子通知大家 Proposer，Acceptor，Learner，State machine 是如何协同工作的。

一个申请发给 Proposer，Proposer 与雷同实例编号为 x 的 Acceptor 协同工作，共同完成一值的确定，之后将这个值作为状态机的输出，产生状态转移，最终返回状态转移后果给发动请求者。

工程化

咱们须要多个角色尽量在一起

**
**

上文提到一个实例，须要有 Proposer 和 Acceptor 两个角色协同工作，另外还要加以 Learner 进行辅助，到了利用方面又退出了 State machine，这外面势必会有很多状态须要共享。如一个 Proposer 必须于 Acceptor 处于雷同的实例能力工作，那么 Proposer 也就必须晓得当前工作的实例是什么，又如 State machine 必须晓得实例的 chosen value 是啥，而 chosen value 是存储于 Acceptor 治理的 Data 数据中的。在概念上，这些角色能够通过任意的通信形式进行状态共享，但真正去实现，咱们都会尽量基于简略，高性能登程，个别咱们都会将这些角色同时交融在一个机器，一个过程外面。

下图例子是一个工程上比拟惯例的实现形式。

这里提出一个新的概念，这里三台机器，每台机器运行着雷同的实例 i，实例里整合了 Acceptor，Proposer，Learner，State machine 四个角色，三台机器的雷同编号实例独特形成了一个 paxos group 的概念，一个申请只须要灌进 paxos group 外面就能够了，跟依据 paxos 的特点，paxos group 能够将这个申请能够随便写往任意一个 Proposer，由 Proposer 来进行提交。Paxos group 是一个虚设的概念，只是为了不便解释，事实上是申请随便丢到三台机任意一个 Proposer 就能够了。

那么具体这四个角色是如何工作的呢。首先，因为 Acceptor 和 Proposer 在同一个过程外面，那么保障他们处于同一个实例是很简略的事件，其次，当一个值被确认之后，也能够很不便的传送给 State machine 去进行状态的转移，最初当出现异常状态，实例落后或者收不到其余机器的回应，剩下的事件就交给 Learner 去解决，就这样一整合，一下事件就变得简略了。

咱们须要严格的落盘

**
**

Paxos 协定的运作工程须要做出很多保障(Promise)，这个意思是我保障了在雷同的条件下我肯定会做出雷同的解决，如何能实现这些保障？家喻户晓，在计算机外面，一个线程，过程，甚至机器都可能随时挂掉，而当他再次启动的时候，磁盘是他复原记忆的办法，在 paxos 协定运作外面也一样，磁盘是她记录下这些保障条目标介质。

而个别的磁盘写入是有缓冲区的，当机器当机，这些缓冲区依然未刷到磁盘，那么就会失落局部数据，导致保障生效，所以在 paxos 做出这些保障的时候，落盘肯定要十分严格，严格的意思是当操作系统通知我写盘胜利，那么无论任何状况都不会失落。这个咱们个别应用 fsync 来解决问题，也就是每次进行写盘都要附加一个 fsync 进行保障。

Fsync 是一个十分重的操作，也因为这个，paxos 最大的瓶颈也是在写盘上，在工程上，咱们须要尽量通过各种伎俩，去缩小 paxos 算法所须要的写盘次数。

万一磁盘 fsync 之后，依然失落或者数据错乱怎么办？这个称之为拜占庭问题，工程上须要一系列的措施检测出这些拜占庭谬误，而后选择性的进行数据回滚或者间接抛弃。

咱们须要一个 Leader

**
**

因为看这篇文章的读者未必晓得 paxos 实践上是如何去确定一个值的，这里简略阐明一下，paxos 一个实例，反对任意多个 Proposer 同时进行写入，然而最终确定进去一个雷同的值，外面是使用了一些相似锁的办法来解决抵触的，而越多的 Proposer 进行同时写入，抵触的激烈水平会更高，尽管齐全不障碍最终会确定一个值，然而性能上是比拟差的。所以这里须要引入一个 Leader 的概念。

Leader 就是领导者的意思，顾名思义咱们心愿有一个 Proposer 的领导者，优先由他来进行写入，那么当在只有一个 Proposer 在进行写入的状况下，抵触的概率是极小的，这样性能会失去一个飞跃。这里再次重申一下，Leader 的引入，不是为了解决一致性问题，而是为了解决性能问题。

因为 Leader 解决的是性能问题而非一致性问题，即便 Leader 出错也不会障碍正确性，所以咱们只须要保障大部分状况下只有一个 Proposer 在工作就行了，而不必去保障相对的不容许呈现两个 Proposer 或以上同时工作，那么这个通过一些简略的心跳以及租约就能够做到，实现也是非常简单，这里就不开展解释。

咱们须要状态机记录下来输出过的最大实例编号

**
**

状态机能够是任何货色，能够是 kv，能够是 mysql 的 binlog，在 paxos 实例运行时，咱们能够保障时刻与状态机同步，这里同步的意思是指状态机输出到的实例的最大编号和 paxos 运行当中认为曾经确认好值的实例最大编号是一样的，因为当一个实例曾经实现值的确认之后，咱们必须确保曾经输出到状态机并且进行了状态转移，之后咱们能力开启新的实例。但，当机器重启或者过程重启之后，状态机的数据可能会因为本身实现问题，或者磁盘数据失落而导致回滚，这个咱们没方法像上文提到的 fsync 一样进行这么强的束缚，所以提出了一种办法，状态机必须严格的记得本人输出过的最大实例编号。

这个记录有什么用？在每次启动的时候，状态机通知 paxos 最大的实例编号 x，而 paxos 发现自己最大的已确定值的实例编号是 y，而 x < y. 那这时候怎么办，只有咱们有 (x, y] 的 chosen value，咱们从新把这些 value 一个一个输出到状态机，那么状态机的状态就会更新到 y 了，这个咱们称之为启动重放。

这样对状态机的要求将尽量简略，只须要严格的记录好这么一个编号就能够了。当然不记录，每次从 0 开始也能够，但这样 paxos 须要从 0 开始重放，是一个蠢办法。

异步音讯解决模型

**
**

上文说到分布式环境是一个异步通信环境，而 paxos 解决了基于这种环境下的一致性问题，那么一个不言而喻的特点就是咱们不晓得也不确定音讯何时达到，是否有序达到，是否达到，咱们只须要去恪守 paxos 协定，严格的解决每一条达到的音讯即可，这跟 RPC 模型比拟不一样，paxos 的特点是有去无回。

这里先定义一个名词叫 paxos 音讯，这里指的是 paxos 为了去确定一个值，算法运行过程中须要的通信产生的音讯。下图通过一个异步音讯解决模型去构建一个响应 paxos 音讯零碎，从而实现 paxos 零碎的搭建。

这里分为四个局部：

1. Request，即内部申请，这个申请间接输出到 Proposer 外面，由 Proposer 尝试实现一个值的确定。
2. Network i/o，网络 i / o 解决，负责 paxos 外部产生的音讯的发送与接管，并且只解决 paxos 音讯，采纳公有端口，纯异步，各台机器之前的 network i/ o 模块相互通信。
3. Acceptor，Proposer，Learner。用于响应并解决 paxos 音讯。
4. State machine，状态机，实例确定的值 (chosen value) 的利用者。

工作流程：

1. 收到 Request，由 Proposer 解决，如须要发送 paxos 音讯，则通过 network i/ o 发送。
2. Net work i/ o 收到 paxos 音讯，依据音讯类型抉择 Acceptor，Proposer，或 Leaner 解决，如解决后须要发送 paxos 音讯，则通过 network i/ o 发送。
3. Proposer 通过 paxos 音讯获知 chosen value，则输出 value 到 State machine 实现状态转移，最终告诉 Request 转移后果，实现一个申请的解决。
4. 当 paxos 实现一个值的确认之后，所有以后实例相干角色状态进行清空并初始化进行下一个编号的实例。

生产级的 paxos 库

RTT 与写盘次数的优化

**
**

尽管通过咱们在工程化上做的诸多要求，咱们能够实现出一个基于 paxos 搭建的，可挂载任意状态机，并且能稳固运行的零碎，但性能远远不够。在性能方面须要进行优化，方能上岗。因为上文并未对 paxos 实践做介绍，这里大略阐明一下奢侈的 paxos 算法，确定一个值，在无抵触的状况下，须要两个 RTT，以及每台机器的三次写盘。这个性能设想一下在咱们在线服务是十分惨烈的。为了达到生产级，最终咱们将这个优化成了一个 RTT 以及每台机器的一次写盘。(2,3)优化到(1,1)，使得咱们能真正在线上站稳脚跟。但因为本文的重点依然不在实践，这里具体优化伎俩就暂不多做解释。

同时运行多个 paxos group

**
**

因为咱们实例运行的形式是确保 i 实例的销毁能力运行 i + 1 实例，那么这个申请的执行显著是一个串行的过程，这样对 cpu 的利用是比拟低的，咱们得想方法将 cpu 利用率晋升上来。

一个 paxos group 能够实现一个状态机的输出，但如果咱们一台机器同时有多个状态机呢？比方咱们能够同时利用 paxos 实现两种业务，每个业务对应一个状态机，互不关联。那么一个 paxos group 调配一个端口，咱们即可在一台机器上运行多个 paxos group，各自端口不同，相互独立。那么 cpu 利用率将能大幅晋升。

比方咱们想实现一个分布式的 kv，那么对于一台机器服务的 key 段，咱们能够再在外面宰割成多个 key 段，那每个小 key 段就是一个独立的状态机，每个状态机搭配一个独立 paxos group 即可实现同时运行。

但一台机器搞几十个，几百个端口也是比拟肮脏的手法，所以咱们在生产级的 paxos 库上，实现了基于一个 network i/ o 搭配多组 paxos group 的构造。

如上图，每个 group 外面都有残缺的 paxos 逻辑，只须要给 paxos 音讯减少一个 group 的标识，通过 network i/ o 的解决，将不同 group 的音讯输送到对应的 group 外面解决。这样咱们一台机器只须要一个公有端口，即可实现多个状态机的并行处理。

至此咱们能够取得一个多个 paxos group 的零碎，残缺构造如下：

更快的对齐数据

**
**

上文说到当各台机器的以后运行实例编号不统一的时候，就须要 Learner 染指工作来对齐数据了。Learner 通过其余机器拉取到以后实例的 chosen value，从而跳转到下一编号的实例，如此重复最终将本人的实例编号更新到与其余机器统一。那么这里学习一个实例的网络延时代价是一个 RTT。可能这个提早看起来还不错，然而当新的数据依然通过一个 RTT 的代价一直写入的时候，而落后的机器依然以一个 RTT 来进行学习，这样会呈现很难追上的状况。

这里须要改良，咱们能够提前获取差距，批量打包进行学习，比方 A 机器 Learner 记录以后实例编号是 x，B 机器是 y，而 x < y，那么 B 机器通过通信获取这个差距，将 (x,y] 的 chosen value 一起打包发送给 A 机器，A 机器进行批量的学习。这是一个很不错的办法。

但依然不够快，当落后的数据极大，B 机器发送数据须要的网络耗时也将变大，那么发送数据的过程中，A 机器处于一种闲暇状态，因为 paxos 另外一个瓶颈在于写盘，如果不能利用这段时间来进行写盘，那性能依然堪忧。咱们参考流式传输，采纳相似的办法实现 Learner 的边发边学，B 机器源源不断的往 A 机器输送数据，而 A 机器只须要收到一个实例最小单元的包体，即可立刻解开进行学习并实现写盘。

具体的实现大略是先进行一对一的协商，建设一个 Session 通道，在 Session 通道里间接采纳直塞的形式无脑发送数据。当然也不是齐全的无脑，Session 通过心跳机制进行保护，一旦 Session 断开即进行发送。

如何删除 Paxos 数据

**
**

Paxos 数据，即通过 paxos 确认下来的有序的多个值，前面咱们称之这个为 paxos log，这些 log 作为状态机的输出，是一个源源不断的。状态机的状态是无限的，但输出是有限的，但磁盘的空间又是无限的，所以输出必然不能长期保留，咱们必须找到办法来把它删除掉。

上文说到咱们要求状态机记录下来输出过的最大实例编号，这里定义为 Imax，那么每次启动的时候是从这个编号后开始重放 paxos log，也就是说小于等于这个编号 Imax 数据是没用的了，它不会再次应用，能够间接删除掉。但这个想法不够周全，因为 paxos 是容许少于多数派的机器挂掉的，这个挂掉可能是机器永远离线。而这种状况咱们个别是用一台新的机器代替。这台新的机器要干什么？他要从 0 开始重放 paxos log，而这些 paxos log 从哪里来？必定是 Learner 找别的机器拷贝过去的。那别的机器删了怎么办？凉拌。

但也并不是没方法了，我能够把这台机状态机相干的数据全副拷贝到新机，而后就能够从 Imax 来启动了，那么天然就不须要 [0,Imax] 的 paxos log 了。然而状态机的数据是无时无刻不在写入的，一个正在写入的数据去拷贝进去，呈现什么状况都是不可预期的，所以这个办法并不能简略的实现，什么？停机拷数据？别逗了。但这个思路给了咱们一个启发。

咱们须要的是一个状态机的镜像数据，这个数据在咱们须要去拷贝的时候是能够随时进行写入的，那么只有咱们有了这个镜像数据，咱们就能够删除 paxos log 了。

Checkpoint

**
**

这个状态机的镜像数据咱们就称之为 Checkpoint。如何去生成 Checkpoint，一个状态机能在不停写的状况下生成一个镜像数据么？答案是不确定的，看你要实现的状态机是什么，有的或者能够并很容易，有的能够但很难，有得可能根本无法实现。那这个问题又抛回给 paxos 库了，我要想方法去给他生成一个镜像数据，并且由我管制。

一个状态机能构建出一份状态数据，那么搞一个镜像状态机就能够同样构建出一份镜像状态数据了。

如上图，用两个状态转移完全一致的状态机，别离治理不同的状态数据，通过灌入雷同的 paxos log，最终进去的状态数据是完全一致的。

在真正生产级的 paxos 库外面，这个个性太为重要了。咱们理论实现通过一个异步线程来构建这个镜像数据，而当发现其余机器须要获取这份数据的时候，能够很轻易的进行线程的工作，使得这份数据不再写入。最初发送给别的机器应用。

在目前的实现版本，咱们真正做到了删 paxos log，新机启动获取 checkpoint，数据对齐的齐全自动化。也就是说，首先程序会依据磁盘应用状况主动删除 paxos log，其次，程序主动的通过镜像状态机生成 checkpoint，最初，当一个新机器启动的时候，能够主动的获取到 checkpoint，而后通过 Learner 主动的对齐剩下的数据，从而主动的实现无人工染指的机器更换。

正确性保障

分布式算法是很难在工程下来验证他的正确性的，咱们只能在工程上利用各种伎俩去靠近正确，这里包含了运行前的测试，运行中的对账，拜占庭问题的细化解决。

模仿异步通信环境

**
**

咱们对算法内核的构建过程中，应用了内存队列来模仿网络通信，应用一个过程来模仿一个机器。过程通过内存队列来通信。咱们对内存队列加以批改，使其反对出队的提早，失落，以及乱序，使得整个通信过程能按咱们配置的形式来运行。咱们通过配置不同的失落率，延迟时间，以及乱序水平，验证不同参数结构的环境下，paxos 的工作成果以及一致性是否失去保障。而咱们通过钩子将过程频繁杀掉重启，以及写盘方面的管制，模仿机器当机重启。

运行时的对账

**
**

采纳 crc32 算法，对有序的多个值进行累加校验，失去一个以后数据版本的校验值，通过一直的在运行过程中比对每个以后编号实例对应的累加数据校验值，一旦发现机器间校验值不雷同，则进行 core 的解决，避免谬误持续扩散。

避免拜占庭问题带来的谬误

**
**

对于所有磁盘写入的数据，都须要进行二次校验，避免磁盘数据被串改。在发现数据被串改后，能及时的回滚到上一个校验胜利的数据，并产生报警。

最初

因为篇幅问题，这里还有更多的有意思的优化，以及更为细节的乏味的问题，就先不做探讨了。置信大家也发现了，这篇文章通篇都在说确定一个值，确定一个值，但就没说到底是怎么去确定一个值的。如果你感觉这篇文章乏味对你有启发，那就去找下论文钻研一下 paxos 到底是怎么确定一个值的吧。

​ 本文系微信后盾团队, 如有进犯, 请分割咱们立刻删除

github 开源地址：

https://github.com/tencent-we…

OpenIMgithub 开源地址：

https://github.com/OpenIMSDK/…

OpenIM 官网：https://www.rentsoft.cn

OpenIM 官方论坛：https://forum.rentsoft.cn/

更多技术文章：

开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…

【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…