paxos深入

  之前学习了paxos，这里总结下。

  写了个paxos实现程序，能够进行选举。

  代码地址：https://github.com/zhaozhenzuo/paxos

  

   总结如下：

    

paxos是分布式无中心结点，用于选举出某个提议值的一致性协议。

paxos结点角色：选举完成时有leader(负责客户端写入操作协调),folloer(选民，可投票),candidator(候选人)。

zookeepor使用的zab协议，其中选举协议从paxos引出。

raft协议相对来讲会更加简单，在一个固定选举选期内，每个投票者只能投一票。

举个例子，a,b,c,d,e,f五个结点。a发现当前无leader在选举届数1发起选举，值为［a］，假设a得到了4票及以上，则选举成功。

极端情况下，b也发起选举，这时假设a,b同时得到3票，此次选举失败。随机睡眠一段时间后下一个选举届数再做选举。

它解决不了拜占庭问题.

拜占庭问题，主要有两个原因导致：结点有可能挂了，通信等不确定问题。还有一个就是结点判变问题。

这里解决不了判变问题，在计算机中就是某几个结点被恶意控制。

对于写入业务来讲，只有一台写入master，能够保证一致性。但这台主机挂了就会导致整个服务不可用。

这时解决方法如下：

增加个slave（只读），再增加个keepAlive进程用于监控写入master。业务向写入master写入值时，同步到从服务器。当写入master挂掉时，keepAlive能够监控到并使slave升级为写入master。

这里有几个问题：

1.如何保证keepAlive监控到写入master挂掉的信息一定是可靠的？

即有没有可能存在写入master还存活，然后将slave也升级为master，相当于就出现双写主机。双写，对于对于变量很难保证一致性。

2.keepAlive本身存在单点问题

paxos无中心特性，可以用于解决上述方案的问题。

paxos工作流程如下：

1.一阶段，集群中各个结点提议自己的值发给接收者 （提议者处理）

这里提议信息如下：

提议届数，提议号，提议值

2.提议接收者，接收到一阶段提议信息时 （提议接收者处理）

进行如下判断：

a.当前提议届数是否小于当前保存届数，如果小于则返回拒绝。

b.当前提议号是否小于当前结点已保存一阶段的最大提议号时，返回拒绝，并带上［小于当前提议号n的已接收到的最大提议值］。

c.其它情况，接收该提议，并保存最大提议案在结点本地，并返回［小于当前提议号n的已接收到的最大提议值］。

3.一阶段，提议发送者接收到提议接收者一阶段响应时 (提议者处理)

看最终接收者是否超过半数，如果超过，则根据以下方法决定二阶段提议值：

当前接受该提议的接受者返回信息中，看［二阶段保存的最大值］是否存在，如果不存在则提议者自己决定值。

如果存在，则取接受者返回信息中最大提议号对应［二阶段保存的值］做为二阶段提议值。

这里提议值为什么始终不是自己决定？

这里主要是解决以下问题：

提议者a发起提议号是1，其值为v1的提议给集群。然后一阶段及二阶段都成功了。这时提议者a挂了。其它结点在隔一段时间后发现还没leader，则会再次发起提议。

这里能够发现，对于新提议是要能够被处理的，否则由于提议者a挂了，就不能工作了。

如果这时新提议号2,值为v2,一阶段时被集群接受。二阶段时提议者自己决定提议值还是v2，这时如果a过一段时间活了，或者只是广播选举结果慢。最终会出现集群结果不一致(a的提议号是1,值为v1)。

所以解决这个问题，最终是采用集群中接受到的小于当前提议号2的，最大提议号对应的值，这里是v1作为二阶段提议号。

这里也同样要求该提议接受数大于集群一半，防止脑裂的情况。

4.二阶段，提议接受者，接收到二阶段提议时 （提议接受者处理）

验证：如果当前提议号小于当前已保存的最大一阶段提议号时，则拒绝。

否则保存当前二阶段接收到的最大提议号及值。并返回接受。

5.二阶段，提议者接受到二阶段响应时

看同意数是否超过一半，如果超过一半则进行广播选举结果，增加本地选举届数。

广播选举结果.