带你一步步走入Paxos的世界 -- 序列2

在上一篇我们谈到了复制日志的问题，每个node上面存储日志序列，node之间保证日志完全一样。

可能有人会疑问：为啥我要存储日志，直接存储最终的数据不就行了吗？

复制状态机

日志与状态机

我们可以把一个变量x，或者复杂一点，一个对象，看成是一个状态机。每1次写请求，就是一次导致这个状态机发生变化的事件，也就是日志。

以上篇最简单的一个变量x为例，只有1个node，3个客户端发送了3个修改x的指令，最终结果就是如下形式：

再复杂点，以mysql为例，客户端发送各种DML操作，这些操作落成binlog。然后binlog被应用，生成各种db表格。就是如下形式：

而在这里，就涉及到一个非常非常重要的思想：我们选择持久化导致数据（状态机）发生变化的“事件流（也就是日志流）”，而不是选择持久化“数据本身”。

为啥要这么做呢？原因有很多，我列举几个：
（1）日志只有1种操作，就是append。而数据（或者说状态），一直在变化，可以add/delete/update。把3种操作转换成了1种，这对于持久化存储来说，一下子就简单了很多！！
（2）如果我要做多机之间数据同步，如果你直接同步状态，状态本身的数据结构可能是一个很复杂的数据结构（比如关系数据库的关联表，树，图），并且状态还一直在变化，你要保证多个机器数据一致，要做数据比对，就很麻烦；而如果同步日志，日志是一个1维的线性序列，要做数据比对，非常容易！！

总之，无论从持久化，还是数据同步角度，存储状态机的输入事件流（日志流），都比存储状态机本身要更容易。

复制状态机

我们知道，状态机的原理就是：一样的初始状态 + 一样的输入事件 = 一样的最终状态。

因此，要保证多个node的状态完全一致，只要保证多个node的日志流是一样的就可以了！！即使这个node挂了，重启，重放这个日志流，就能恢复之前的状态。

也因此，我们就回到了上1篇最后的问题：复制日志！

复制日志 = 复制任何数据（复制任何状态机）。因为任何复杂的数据（状态机），都可以通过日志生成！！！

Multi Paxos与Basic Paxos

Paxos的出现，是先有Basic Paxos的形式化证明，之后再有Multi Paxos，然后是应用场景。因为最开始没有先讲应用场景，所以直接看Basic Paxos的证明，会很晦涩。

本文将反过来，就以上一篇最后提出的那个问题为例，先介绍应用场景，再一步步倒推出Paxos, Multi paxos。

一个朴素而深刻的想法

上文讲到，当3个客户端并发的发送3个请求时，下面6种可能的结果都是对的！！

因此，我们就是要找一种算法，保证虽然每个客户端是并发的发送请求，但最终3个node记录的日志，一定是同样的顺序！！（上面之1）

那如何做到呢？？？这里我提出一个朴素而深刻的说法：全世界对数字1，2，3，4，5，6。。。的顺序的认知，是一样的！！！所有人、所有机器，对这个的认知都是一样的！！

什么意思呢？ 当我说2的时候，全世界的人，都知道2是在1的后面，3的前面！！！2代表1个位置，这个位置一定在在(1,3)之间。

我们把这个朴素的想法，应用到计算机里面，多个node直接复制日志，就变成如下这样：

当node1收到x=1的请求时，假设我要把它存放到日志中1号位置，先不要存，我先问一下另外2台机器，1号位置是不是已经存放了x=3或者x=5；如果1号位置被占了，那我就问2号位置。。。以此类推；如果1号位置没有人占，我就把x=1存放到1号位置，同时告诉另外2个node，把x=1，存放到它们各自的1号位置！！

同样, node2, node3做同样的事情。

这里的关键思想就是：虽然每个node接收到的请求的顺序不一样，但它们对于日志中1号位置、2号位置、3号位置的认知是一样的，大家一起保证，1号、2号、3号上面，存储的数据一样！

2PC

在上面的例子中，我们可以看到：每个node在存储日志之前，先要问一下其他所有人，之后再决定把这条日志写到哪个位置。

这也就是2个阶段：先问，再做决策。也就是Paxos 2PC的原型！！

Basic Paxos

把上面的问题再进一步拆解，不是3条日志，就1条。我们就先确定3个node的第1号日志，看有什么问题？

node1问了其他所有人，1号位置没有被占，因此它打算把x=1传播给node2/node3；
同样的时刻，node2问了其他所有人，1号位置也没有被占，因此它打算把x=3传播给node1/node3；
同样，node3也打算把x=5传播给node1/node2。

结果不就冲突了吗。到这里，大家就发现，不要说多条日志，就算是只确定第1号位置的日志，都是个问题！！！

而Basic Paxos就是用来解决这个问题：它怎么解决的呢？

1号位置，要么是被node1占领，大家都存放x=1；要么被node2占领，大家都存放x=3；要么是被node3占领，大家都存放x=5。

Basic paxos就搞了2条主要思路：
第1：1号位置的值一旦被大多数确定了，比如是x=5（node3占领了, node2从了node3），那我就接受这个事实。1号位置不能用了，我也得把自己的1号位置赋值成x=5。然后我就看看2号位置，看能不能把x=1存进去，同样的，如果2号也被占领了，我就只能把人家的值拿过来，填在我的2号位置。我就只能看3号位置。。。

第2：当我发现1号位置没有人占，那就告知其他人，锁定这个位置。不允许有人再占这个位置！除非这个人的权利比我大（也就是proposal id比我大）。

如果我发现1号位置为空，然后提交的时候，发现1号位置被别人占了，那就会提交失败，重试，进入第2个位置。。。

Multi Paxos

上面讨论的Basic Paxos只是保证1号位置的日志，在3个node上面1样。并且我们发现，为了让1号位置日志一样，可能要重试好多次，每个节点都会不断重试2pc。

这样一个不断重试2pc，直到最终大家达成一致的过程，就是paxos协议执行的过程，也就是一个paxos instance，最终确定一个值。

而Multi paxos，就是重复这个过程，确定一序列值，也就是日志中的每1条！！

最后

本篇从一个朴素的思想出发，最后引出paxos要做什么。下一篇，我们将详细讨论Paxos算法本身。