分布式（二）

Paxos

曾经的王者，被鞭尸的存在

Base-paxos

paxos的目的是保证一个提案在所有服务器上都达成一致。

基本操作就是：任何服务都可以进行提案，如果得到大多数服务同意，则提案通过。

但是各个机器是独立的，提案可能就会冲突，所以paxos中采取以下策略：

1. 每个机器维护一个自己知道的最大的消息编号。

2. 提案者2步提案，prepare的阶段会去同步各个节点信息，在得到大多数投票之后开始commit

   1. 同步各个节点信息具体为：acceptors在响应prepare请求的时候，会把当前已经接受的提案号和提案值返回，而提案者会取其中最大提案号的提案值 来进行提案。
   2. 提案者需要根据接收者的消息 更新提案的信息

image.png

3. 接收者需要根据提案信息，更新 自己知晓的最大提案号，自己接收的值等。

其实，现在来看，paxos就是这么简单。通过上面简单的协议，我们就可以保证对于同一个提案，所有机器保持一致。

此外，paxos 也要求所有服务 把自己的状态 落盘到本地。

除次，paxos没有其他保证崩溃恢复的措施，并且对于一些acceptor 也没有办法去保证同步。更别提水平扩展了。

在笔者看来，paxos与其说是一个协议，更新是一个想法和思考。它给了大体的方向，但是工程实现了比较欠考虑。也正因为如此，目前业界很少有paxos的完整实现。都paxos的理解也比较容易停留在paper层面。

paxos的目的仅仅是提案在所有服务上达成一致，也就有了下面的问题

1. 不能保证所有服务都取到了一致状态，因为 提案者只需要保证大多数接收者取到新的状态就OK了。
   1. 心跳包机制欠缺？
2. commit属性的丢失，我们不知道一个提案是否已经提交。
   1. 所有的接收者是不知道一个提案是否已经被真正的提交了的
   2. 提案者如果崩溃恢复也不知道一个提案是否被提交
3. 提案的顺序性没有保证，这对状态机原理是致命打击
4. 活锁问题，2个提案者 交替提案
5. 提案流程太长 => 流程越长，变故越过，成功率越低

迷惑点

multi-paxos

正因为base-paxos的一些问题，提出了multi-paxos。

img

multi-paxos针对上面的问题，主要的变动有以下2点：

1. 新增了leader的概念
2. 新增了index的概念，日志按照index存储。

那么下面我们就具体说下 multi-paxos 几个点的优化

1. 日志（提案）保持同步

   在base-paxos中，除非提案者发起提案申请，不然是不会进行日志同步的，那么 我们很难保证一个机器上拥有完整的提案。 所以在m-paxos中，如果我们有新的提案，需要保证该提案前的日志同步。

image.png

2. 新增index,保证日志执行按照顺序。只有被chosen，commit的消息才可以执行。且保证之前的消息都执行完成。

3. 新增leader，保持同一时间一个提案者

   减少不必要的竞争，比如活锁问题会大大减少

   leader选举规则paper未列出，目前有的方式如下：

   1. ID最高的为leader，心跳包保证竞选。
   2. 租约模式

4. prepare信息丰富，一次leader的prepare携带多条日志

5. 提案完整复制

   1. 提案者在后台持续尝试 Accept RPCs 直到所有 acceptors 返回OK。

6. commit信息特殊设计

   1. 使得commit的信息 提案号为正无穷
   2. 提案者把已经提交的信息 通知给到 acceptor