分布式事务特性，分布式事务处理

Posted 2022-10-25 spark9988

1：分布式事物的理解： 

     分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，分布式事务需要保证这些小操作要么全部成功，要么全部失败;本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2：分布式失误产生的原因：

a）数据库分库分表;

   当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

 

b)应用SOA化；

就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心等,对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

 

以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了。

3）分布式的使用场景：

支付：一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败，并且卖家账户对应卖家数据库,买家对应买家的数据库，对不同数据库的操作必然需要引入分布式事务。

在线下单：在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态,库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

4）常见的分布式事物解决方案：

a）基于XA协议的两阶段提交，

    XA是一个分布式事务协议,XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。

 

   XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也，XA也有致命的缺点，那就是性能不理想,往往并发量很高，XA无法满足高并发场景。

b)消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性。

具体原理：

 

其执行的顺序：

b.1)A系统向消息中间件发送一条预备消息;

b.2)消息中间件保存预备消息并返回成功;

b.3)消息中间件保存预备消息并返回成功；

b.4)A发送提交消息给消息中间件；

对于这个顺序执行的分析：

   步骤一出错，则整个事务失败，不会执行A的本地操作;

   步骤二出错，则整个事务失败，不会执行A的本地操作；

   步骤三出错，这时候需要回滚预备消息,回滚方法,：A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息。

 步骤四出错,这时候A的本地事务是成功的，回滚本地A操作的成功,不需要回滚：其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务。

c）高并发场景下基于消息中间件的两阶段提交的分布式事物：

 比如：将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作

 

   B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作。如果B本地操作失败，消息会重投,直到B操作成功。这样就变相地实现了A与B的分布式事务。

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的,当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

d）TCC编程模式,

TCC编程模式，也是两阶段提交的一个变种。

TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。

  以在线下单为例：Try阶段会去扣库存,Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存,TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

4)总结：

分布式事务，本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务;部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式;完全控制就是完全实现两阶段提交。

部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景
————————————————
版权声明：本文为CSDN博主「wanghang88」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wanghang88/article/details/79762761