# 概念
分布式一致性算法基本被Paxos占领了，大部分的实现都是基于Mutil Paxos的变种
另外一类分布式系统使用的复制的方法（EC其实也是复制的一个变种），比如glusterfs
glusterfs 通过一个afr translator将数据写往多个节点，只要有一个成功就可以返回成功响应了。
这种方式在主备节点切换宕机之后，可能出现脑裂的现象，这个问题其实就是复制模式解决分布式一致性遗留下来的。
glusterfs需要手工介入来完成数据修复，它的好处也比较明显，就是不需要那么负责的一致性协议，数据直接写入目标节点。
# Multi Paxos
上面讲到了目前大部分的分布式一致性的算法实现都是基于Multi Paxos及其变种，如Raft、ZAB
最主要的原因是Paxos算法每一次数据提交都需要两次网络交互，还有可能提案冲突，实现难度和性能代价比较大。
而对于一个三备份或者五备份的存储数据来说，节点出现异常的时间远远小于正常工作的时间.
这样的话，大部分时间都不需要考虑CAP中的P的问题，Multi Paxos刚好能解决这个问题；
先选择一个可信任的节点，在不发生P问题的时间里，大家都无条件的信任它，所有的提议都由它发起，其他人追随它即可。
Multi Paxos的问题就是，当大家都信任的那个节点异常之后，怎么快速感知并选择一个新的课信任的节点。
在新节点选择出来之前，怎么保证系统的A。
# 不稳定的时间点的可用性
这个问题在算法论文里面并没有详细说，所以每个系统的实现也完全不同。大部分系统在这种情况下，会出现短暂的业务中断，
周期取决于新的Leader被选择出来
比如raft，在Old Leader宕机之后，fllower通过心跳感知到leader过期之后，选举一个新的Leader，新的Leader产生前需要
将Log补全，因为raft算法只保证leader拥有全量log，fllower在成为leader之前需要将所有fllower的log收集起来以补全log
之后才能成为一个真正的Leader。这个过程如果log数据很大的话，业务中断的时间也会比较长
# 一种不中断业务的算法
在客户端感知到了Leader不通时，可以把成员里面拥有log id最大的flower设置成为临时的Leader。在新的Leader选择出来之前
所有请求都通过它完，这个时间段不需要中断业务。
但这个算法要求新的Leader在拥有全量数据之前，不能将Membership发布出去，因为这样一来临时的Leader就会失效。
所以算法要求Leader的选举过程由一个上帝完成，先选一个上帝，然后由上帝监控Leader完成它的工作，之后Leader就可以发布消息说
我成为了新的Leader。
