分布式事务如何保障一致性

一、2PC：

通过2PC，但需要丧失CAP的A特性，如果部分服务不可用，则无法实现整个事务提交

 

二、Paxos或Zookeeper：

（一）、Paxos：

偏向C，弱化A；但也要求至少N+1结点同时操作，在可用性（性能和吞吐量）方面也打了不少折扣。主要应用于同时两个人要改一件事情，到底以谁的为准。Paxos的游戏场景：

甲乙两个客户端分别提交100、200两个事务，其中100需要把数据库比如学生姓名改为张三，200事务改成李四，后台有三个数据库服务器A、B、C。时间顺序为：

1、100咨询张三A、B、C是否可以 预提交，A、B 口头答应，C没有答复；甲客户端收到100的返回值，超过半数，因此100事务让A、B去提交（拿合同去签订）

2、C恢复，200咨询B、C事务否可以提交，由于200>100，因此B、C口头同意200；乙客户端收到B、C口头允诺后，也去签订合同

3、100成功与A签署合同，但B拒绝签署合同。甲知道这个事情后，同意200事务变成李四，继续征求A、B、C意见

4、200成功与A、B、C签署合同

5、最终同意姓名改为李四

（二）、Zookeeper：

ZAB协议为Paxos变种，主要应用场景为数据主备，一般由主提供服务，主挂了，再有小弟顶上

ZK核心就是一个提供目录服务的、不存在单点故障的数据库。最初理解Zookeeper时似乎很容易通过数据库或者其他共享文件方式实现，但是它的优势优势或者场景在于不存在单点故障，保证多个子节点宕机依然可以提供服务，从而可以帮助其他Master节点避免单点故障。

1、首先对比普通目录服务，如果共享文件服务器挂掉怎么办？

2、再说数据库，一般数据库集群两种模式，一种是同步复制，需要所有节点完全一致才能完成事务提交，但这样不满足A；或者主从异步复制，但如果此时某个节点故障，则不满足C。

当然上述场景主要是针对互联网中大数据并发下才会存在的情况，普通企业级应用通过单机数据库即可实现，或者利用Oracle等商业成熟软件具有的成熟模型；

但是毕竟开源单机数据库性能不足，而Oracle在数据量特别大的情况下成本高且同开源数据库一样，有数据量瓶颈。

 

三、最终一致性：

（一）、BASE理论，设置中间状态，当被调用服务恢复执行后，调用服务继续往后走，达到最终一致