Paxos

最朴素的Paxos需要解决的问题：确定一个值，暂时不需要去想更多的东西，聚焦在确定一个值这么一个看似非常简单的事情身上。

单一的 acceptor

确定一个值最简单的方式就是只使用一个acceptor，每个提出来的 proposal 都会被确定下来。但是这样子会出现的问题是，当这个acceptor节点奔溃或者是失联的时候，服务就会变成不可用状态。所以我们的acceptor的个数需要使用多个（3，5，7），让多数的acceptor来确定一个 value。

acceptor 只是接受第一个 proposal

但是这样子的话，会有很多个proposal被不同的acceptor接受，导致无法决定出一个最终的 value。

Screen Shot 2019-05-14 at 22.16.10.png

acceptor 接受所有的proposal

出现了新的问题，就是说开始时 1/2+的节点都接受了red，但是接下来却又接受了新的 proposal。所有不能够最终决定出一个 value。

Screen Shot 2019-05-14 at 22.18.24.png

acceptor 只接受新的 proposal，不接受旧的。

刚开始的时候 s1 确定自己是最新的 proposal，但是由于网络延迟，导致了 后来的 blue 值被大多数acceptor接收到，但是 s1 还是接受的是 red，导致最终不一致。

Screen Shot 2019-05-14 at 22.22.45.png

两阶段

1. 广播 prepare rpc
2. 广播 accept rpc

Screen Shot 2019-05-14 at 22.28.42.png

当 prepare rpc 4.5 到达 s3 的时候，发现它已经接受了值x，所以Y就会变成 x，确定了一个值。

Screen Shot 2019-05-14 at 22.30.17.png

但是与此同时，这个方案还是存在了一些问题。
s3 收到了 P3.1，但是还没有接受，P4.5 到了，s3 做出承诺 不在接受小于P4.5 的 proposal。所以不同的服务器 不能够确定一个值。

Screen Shot 2019-05-14 at 22.30.17.png

当存在一定的延迟的时候，s3 不能够确定任何一个值，而 s1，s2 确定了 X，s4，s5 确定了 Y。

Screen Shot 2019-05-14 at 22.36.19.png

Multi-Paxos

1. paxos lecture