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

esbaoly

2015-07-14

关注关注

一、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理论，设置中间状态，当被调用服务恢复执行后，调用服务继续往后走，达到最终一致

分布式事务 background 数据库一致性

esbaoly

0 关注 0 粉丝 0 动态

关注关注

分布式事务的实现

在微服务架构中，随着服务的逐步拆分，数据库私有已经成为共识，这也导致所面临的分布式事务问题成为微服务落地过程中一个非常难以逾越的障碍，但是目前尚没有一个完整通用的解决方案。其实不仅仅是在微服务架构中，随着用户访问量的逐渐上涨，数据库甚至是服务的分片、分区、

粗茶淡饭 2020-06-25

分布式事务的现象及理解

在微服务环境下，因为会根据不同的业务会拆分成不同的服务，比如会员服务、订单服务、商品服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务产生的原因。Jta+

xiaoxiangyu 2020-04-30