二：Paxos补充

分布式系统中，最经典的问题就是如何作到分布式环境下的数据一致性

对于这个问题产生了CAS，Base理轮，等经典理论的探讨

那么什么是分布式一致性：集群中的状态保持一致，不管访问集群中的那台机器，返回的数据都是一致的，这就是最笼统的分布式一致性。

一致性：强一致性，作不到

顺序一致性：读一个读写操做的集合全部进程看到的都是同样的顺序

因果一致性：顾名思义，保证全部因果操做关系的一致性

最终一致性：容许存在中间状态，可是能够保证数据最终的一致性

下面咱们来一看下载BackUp，Master/Salve,Master/Master/2pc,Paxos算法

1	Backups	M/S	MM	2PC	Paxos
Consistency(一致性)	Weak.
由于通常都是定时策略，因此会有很长时间的不一致	最终一致性	最终一致性	Strong	Strong
Transaction(事务)	不支持	Full	Local	Full	Full
Latency(延时)	高	低	低	高	高
throughput(吞吐量)	高	高	高	低	中等
Data loss	lots	Some	Some	None	None
Failover	Down	Read only	R/W	R/W	R/W

 

2pc：

    顾名思义，就是两端提交，分为PrePare和Do Commit两个阶段

    1：PrePare阶段：协调者向集群中的参与者发出Prepare请求，参与者选择恢复（Yes/No）,进入这个阶段后，参与者会记录自己的状态，而且保持一个阻塞状态

    2：Do Commit阶段：若是协调者接收到集群内部全部机器Yes的话，就会发送一个Commit请求，若是有一个参与者不一样意的话那么就会通知回滚。

那么在第一阶段就能够看出来，在参与者反馈后就开始处于阻塞的状态，那么若是有一个参与者挂掉了，那么协调者就会等待，这就会致使效率问题，fh

此外协调者和参与者都有可能出错，这就致使了不能够高可用的问题

Paxos

角色：Proposer提议者，Acceptor批准者

完成一次算法以前，全部的Acceptor都处于一致状态

他也是一种两端提交协议

第一个阶段：Prepare阶段

 Proposer提议者发送一个Prepare阶段，以议案的形式{"sn":n}

    a):若是Acceptor之前没批准过如何议案，那么就会直接返回ok

    b):若是Acceptor之前批准过议案，Acceptor会保留批准过的议案，本地{"sn":j,"value":"v1"},就会对比j和n的值，若是n>=j,那么就会返回{“sn”:“j”，“value”:“v1”}，而且作出如下保证，不会再批准编号小于n的任何议案，若是j>n，那么直接、、

第二个阶段：Accept阶段

       a）：若是发现多数又返回

            a1）：若是多数返回ok，那么就会设定一个本身的值v2，发送议案{"sn"："n"，"value"："v2"}

            a2)：返回中有各类各样的值，就会选择一个最大的值，发送议案{"sn"："x"，"value"："x"}

    b）：若是多数Acceptor返回结果，那么Proposer议案提议者就会认为议案被接受，通知Learner进行学习，完成一次Proposer，不然再次提交。

最简单的就是先学习，若是没有的话就本身定义一个值，若是有返回，选取最大的一个值进行广播，当大多数Acceptor认同了，就ok，通知Learner学习。

可是也有其缺陷的地方，容易出现活锁的状况，互相提交议案，

期间也不能修改v值

并且不能保证最早发起的议案会被执行。

改进以后：Fast

在集群内部选举出一个Leader，只有Leader能够发起Proposer

开始一次算法的时候，Leader发起同步，负责收集消息，而后学习议案，进行广播

知乎大牛的文章不错

https://www.zhihu.com/question/19787937

Pasox made simple中文翻译

http://blog.csdn.net/sparkliang/article/details/5740882