分布式一致性

ACID不适用于分布式环境的下的事务处理，为了满足分布式环境下的事务需求，出现了一些经典理论

CAP定理

一个分布式系统不可能同时满足一致性、可用性、分区容错性，这三个要求，最多只能满足其中两项。

一致性：数据的多个副本能否保持一致的特性。

可用性：对于用户的操作能在有限时间内返回结果。

分区容错性：在系统遇到网络分区故障时（分布在不同子网络的节点，网络不连通），仍然对外提供满足一致性和可用性的服务。

由于分区容错性属于分布式系统基本要求，因此根据业务需求在一致性和可用性之间寻求平衡。

BASE理论

BASE来自基本可用、软状态和最终一致性三个短语的缩写，是对CAP中一致性和可用性权衡的结果。

基本可用：当出现不可预知故障时，系统性能降低，但依然可以提供服务。

弱状态：允许系统在不同节点的数据副本进行数据同步的过程存在延迟。

最终一致性：经过一段时间后，数据达到一致性状态，而不需要时时刻刻达到一致性状态。

最终一致性变种：因果一致性、读己之所写、会话一致性、单调读一致性、单调写一致性

一致性协议

2PC二阶段提交

角色：协调者、参与者（集群中的节点）

阶段一：提交事务请求

             1.协调者向参与者发送事务内容，等待响应

             2.参与者执行事务

             3.参与者向协调者反馈事务执行情况

阶段二：事务提交

             A.所有参与者执行事务成功的情况下

             1.协调者向参与者发送事务提交请求

             2.参与者提交事务

             3.参与者向协调者反馈提交结果

             4.协调者完成事务

             B.参与者执行事务失败的情况下

             1.协调者向参与者发送回滚请求

             2.参与者执行事务回滚

             3.参与者向协调者反馈事务回滚结果

             4.协调者中断事务

缺点：同步阻塞，参与者在等待其他参与者响应的过程中无法执行其他操作。

            单点问题，协调者处于重要地位，易出现单点故障

            数据不一致，发送事务提交请求阶段出错

            太过保守，任意节点出错，都会导致系统不可用

3PC三阶段提交

阶段一：CanCommit

             1.协调者向参与者询问是否能执行事务

             2.参与者向协调者反馈是否能执行事务

阶段二：PreCommit

              A.参与者均能执行事务

             1.协调者向参与者发送事务预提交请求

             2.参与者执行事务操作

             3.参与者向协调者反馈事务执行结果

             B.参与者不能执行事务

             1.协调者向参与者发送中断事务请求

             2.协调者中断事务

阶段三：DoCommit

              A.所有参与者执行事务成功的情况下

             1.协调者向参与者发送事务提交请求

             2.参与者提交事务

             3.参与者向协调者反馈提交结果

             4.协调者完成事务

             B.参与者执行事务失败的情况下

             1.协调者向参与者发送回滚请求

             2.参与者执行事务回滚

             3.参与者向协调者反馈事务回滚结果

             4.协调者中断事务

Paxos

角色 Proposer （提议者 ）、 Acceptor（决策者）、Learner（学习者）

多数派：一组acceptor，数量大于所有acceptor的一半

提案编号n

提案value

阶段一：prepare
   1.Proposer选择一个提案编号n，发送给一个acceptor的多数派
   2.如果acceptor发现n是它已的请求中编号最大的，它会返回已经accept的最大的提案（如果有），同时承诺，不再响应编号小于等于n的prepare请求，不会accept编号小于n的提案
阶段二：accept
   1.如果Proposer接收到了多数派的回应，它发送一个accept消息到（编号n和提案value,value是收到的响应中编号最大的提案,如果回应中不包含任何value，则有proposer随意选择一个）到acceptor的多数派
   2.acceptor接收到accept消息后check，如果未响应比编号n大的提案，则accept这个提案，否则不回应。

这是产生一个决议，也就是确定一个提案的过程。简单说也就是Proposer出一个编号大的提案，并且抢在其他Proposer出更大编号的提案前，被大多数acceptor接受，就产生了决议。那其他Proposer就只能支持这个决议。

ZAB

http://www.tuicool.com/articles/IfQR3u3

ZooKeeper原子消息广播协议

角色：leader、follower

Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Foller服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将一个Proposal进行提交。

ZAB协议中使用ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1，高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID；ZAB使用epoch来区分不同的Leader周期；

Leader选举

每个服务器都会发出一个投票，内容为（myid，ZXID），开始各服务器会将选票都投给自己，并发送给其他服务器，接收投票的服务器会将选票与自己的选票比较，先比ZXID，如果比自己的大，更新自己的票，如果一样，再比myid，比自己的大，则更新选票，再发送给其他服务器，每个Follower中维护着一个投票记录表，当某个节点收到过半的投票时，结束投票并把该Follower选为Leader，投票结束；

阶段一：发现

阶段二：同步

阶段三：广播

Raft

角色：leader、follower、candidate

http://www.jianshu.com/p/4711c4c32aab

http://www.jdon.com/artichect/raft.html