分布式事务

一.概述

当系统分布式，服务化后，涉及到不同服务间事务一致性问题。

如交易涉及库存扣减，支付以及后续的优惠券积分累计。此时如何保证事务的一致性。

下面会先介绍几种事务理论解决方案，然后再详细介绍蚂蚁SEATA分布式事务框架。

二.解决方案

常见的解法有：

1.二阶段事务

2.三阶段事务

3.事务补偿

4.MQ事务消息

这3种解法基本是底层的基础原理涉及的解法，而对于基本某一种解法往往会有相应的具体实现，如tcc就是对应二阶段的解法。

三.详细

1.二阶段事务

二阶段的流程整体涉及二阶段，一阶段由事务管理器询问题各资源方是否能提交事务，如果都可以则进入二阶段的提交。

所以参与者来看会有应用程序，事务管理器，资源参与方。

二阶段的问题主要是网络交互及长时间锁资源带来的性能问题。同时存在如果事务管理器挂了整体集群就run不来了，而之前可能一阶段锁定的资源会迟迟得不到释放。

1.1.XA实现

优：使用简单

缺：需要数据库支持，性能慢，这也是二阶段的特点，网络交互多，锁资源时间长。

可以看到一个事务要来回和事务管理器进行交互，性能很差。

基本原理图：

图片来自文章：分布式事务实战--一个完整的xa例子 - 知乎

2.三阶段

三阶段就是对于二阶段的优化，增加了一个询问阶段来减少后续不成功的概率。

但基本解不了性能问题，以及长时间锁资源问题。

2.1.tcc

三阶段的实现。tcc的缺点除了三阶段有的，对于业务代码侵入很大。需要业务实现try,cancel,confirm接口。

3.事务补偿

3.1.事务记录表

业务执行前先用一个事务表先记录下这个事务，然后业务执行完成后更新下这个事务记录。

如果有异常的通过扫描这个表。

优：能完成功能，且性能比二三阶段分布事务要好，不存在事务管理器挂了的问题。

缺：需要独立的事务表存储，且需要有个job来扫事务表，小业务还好，大业务扫表有性能问题。

4.mq事务消息

用mq的事务消息去做。

在事务开始前先发送一个半事务消息到mq。

然后执行业务事务，如果成功则往mq发成功的事务消息，如果失败则发失败的事务消息。

这期间如果涉及业务事务执行成功但后面成功的事务确认消息没发出去，由mq定时来查状态。

mq事务具体见：rocketMq消息事务_剑八-的博客-CSDN博客

四.蚂蚊seata框架使用

• 是什么

seata是一个分布式事务框架。优点：提供业务快速接入不同事务解决方案。

• 事务模式分类

支持3种事务模式：AT，TCC，长事务SAGA。

模式	优	缺
AT	使用简单，对代码无侵入	性能低：当资源有并发时要加全局锁
TCC	性能较AT高，无锁	对代码有侵入
SAGA(长事务解决方案)	性能较AT高，代码侵入较TCC要好（不需要实现commit,rollback标准接口）	业务要按顺序实现业务单元事务回滚

• 原理

三个角色：事务协调者TC，事务管理器TM，事务参与方RM。

• 高可用架构

•  AT

原理

1、自动解析sql，生成前后镜像(存储到undoLog)，提交本地事务；

2、TM根据执行情况进行commit或rollback：commit时删除undlog；rollback则根据undoLog前镜像进行回滚处理(生成回滚语句并提交)；

优缺点

优：对业务无侵入，commit及rollback相应语句由框架生成；

缺：性能差：需要全局锁将事务隔离级别从默认读未提交提升到读已提交，因此串行；

流程图