我们之前在介绍paxos协议的时候,都是一直在说的神权阶段.通过法案都是一条一条的通过,不会有多条法案同步行进.如今Paxon改革换代,进入了国会阶段,协议也因此有了些变化.

在国会阶段,Paxon需要通过多条法案.主席的功能也在逐渐变大.议员想要发布法案都要向主席申请一个法案序号,然后进行后续的操作.虽然很多条法案可以同步进行,但是只有一个主席在维护着.不过,这次前两步只执行一次，不会随着新的实例出现再多次执行了。

协议诞生

step1

首先主席p给议员们发送$NextBallot(b)$,当然，因为可以通过很多条法案，因此理论上这个集合可以是无限的。

step2

议员q收到了主席的消息，回复$LastVote$（集合），由于一个议员只能够参加指定数量的投票，所以q回复的lastvote集合是有限的。 > 稍微解释下，这个地方我第一遍看的时候有些不解，有限无限的含义。为了方便理解，我们姑且有法案a，法案b，法案c来表述。由于是多条法案同步进行，所以作为发起方，他可以发起很多法案，不局限与a,b,c。然而议员q他能够回复的关于法案a的数目是一定的，他只会投其中某个，比如a=3的法案，其他也如此。

step3

主席收到了回复的$LastVote$，针对法案a，按照定理$B_{3}$选择正确的法案发布出去。只要他收到了要通过法案的请求，他就选择法案序号最小的实例使其通过（这句怎么都不理解什么含义）

修改

为了得到完整的国会协议，还需要对神权协议做一定的修改。 如果一个法案的结果已经知道了，就没必要执行一遍完整的神权协议。（我们之前介绍的）。 之前，牧师是要发送$NextBallot(b)$开始一个新的法案。在现在，主席已经知道序号小于n的法案内容了，因此他就给所有的法案实例a,b,c发送$NextBallot(b,n)$代替原来的$NextBallot(b)$，证明已经知道b了。议员q除了按照正常回复这个$NextBallot(b)$，还要把自己已经记录过得大于n的法案给主席让主席记录，如果自己的法案并不全，就让主席把小于n中自己没有的发给自己。 为了不破坏法案的顺序，序号靠后的已经记录，那么前面没有记录的，就用一个全民公认的法案替代。这样一致性和逻辑正确都可以保证。

协议的特性

法案顺序

由于是多条法案同步进行，因此哪条法案率先通过很难确定。 当法案进行到第三步的时候，我们称之为提案阶段(propose),当法案被记录后，我们叫做通过阶段(pass) 在主席进行步骤三（发起新提案）之前，需要获取之前所有已经通过的提案。然后主席填充那些没有记录在案的空隙。可以得带一个结论。 如果法案A比B先通过，那么A的法案号一定比B靠前。

人员不再变化

这块论文本身也没有做过多阐释，主题步骤与神权协议步骤也很是相似，只是变成了主席的管理。 而且，为了加快效率，某些发送过程可以结合到一起。

改进

主席选举

原文没说比较优秀的解决方案，但是可以肯定，按照字母表的方式选举一定不合适。

法典

随着法令内容的增加，纸条不够用了，变成了书。 为了方便查询，只记录当前的内容，并且每隔一段时间更新一下。

官僚化

有时候一个议员业务繁忙，需要一些其他人进行代为管理，选举官僚。为了修复官僚化带来的弊端，需要给法案加上确认的事件保证一致性。

学习

有的时候由于离线等原因，导致内容并不一定能够跟得上最新进展，需要进行查询记录。为了保证一致性，需要保证新的查询查到的法律内容不能比以前的查询内容旧。 然后也做了一下专家的规定（类似于官僚）

欺骗与过失

发生了不一致情况，如何解决？ 如果已知不一致，好解决，直接通过新的提案即可。但未知呢？就无法解决了。

新议员选举

成员要通过法案选举。但是很不安全，友谊一次记录过失，导致Paxos被东方入侵覆灭了。

计算机科学

状态机的对应。

小结

国会阶段Lamport大神写的实在泰国晦涩难懂，而且我还处在分布式学习的入门阶段，因此实在有些吃力。 有些内容是原本本身就没有介绍太多，有些是我自己无法弄明白详细含义。 如果以后能够理解更为透彻的话，我再来更新本篇文章吧。 Paxos协议的最根本的论文我看完了，也用了将近一个星期的时间弄懂了一些含义。 我才发现我在这深奥的知识面前只是一个彻头彻尾的小学生，还需要努力钻研，勤奋刻苦。 不过收获也是巨大的。以前看到全英文的论文直接解害怕了，不敢读下去，经过这两篇论文的折磨，我也有了继续学下去的动力。 希望未来安好。