1. 分布式事物产生的背景
在微服务环境下，因为会根据不同的业务拆分成不同的服务，比如说会员服务，订单服务，商品服务等。让专业的人做专业的事，每个服务都有自己独立的数据库，独立运行，互不影响。
服务与服务之间通讯采用RPC（dubbo）/http(springCloud)远程调用技术，但是每个服务中都有自己独立的数据源，即自己的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事物产生的原因
解决分布式事物的基本思路
- ACID酸碱平衡理论
如何保证强一致性呢？关系型数据库天生就是解决具有复杂事务场景的问题。关系型数据库完全满足ACID的特性。
数据库管理事务（transaction）的四个特性（分析时根据首字母缩写依次解释）：
原子性（Atomicity）：原子性是指事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
一致性（consistency）：事务开始之前和事务结束以后，数据库的完整性约束没有被破坏，这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
隔离性（Isolation）：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其他事物运行效果。
永久性（Durability）：意味着在事务完成以后，该事务所对数据库所作的更改持久的保存在数据库之中，并不会被回滚。 - CAP
C:Consistency一致性，在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。
A:Availability，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并且响应。
P：Partition tolerance分区容错性。尽管网络上有部分消息丢失，但系统任然可继续工作。
CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
- Base理论
Base理论是指：Basically Available（基本可用）,Soft-state（软状态/柔性事务），Eventual Consistency（最终一致性）。是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。
核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。
基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用，但不等价于不可用。比如搜索引擎0.5秒返回查询结果，但由于故障2秒响应查询结果：网页访问过大时，部分用户提供降级服务。
软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
最终一致性：系统中所有的副本经过一段时间后，最终能达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计，追求强一致性模型。
柔性事务和刚性事务
柔性事务满足Base理论（基本可用，最终一致）
刚性事务满足ACID理论
柔性事务分为：
两个阶型
补偿型
异步确保型
最大努力通知型集中
分布式事物解决方案
前面谈了很多关于分布式事物方案的一些思想，那么接下来给大家深入讲解如何彻底解决分布式事物。
- 传统的Jta+Atomikos
- 2PC与3PC实现
- 支付回调通知补偿型
- 使用阿里巴巴TCC补偿框架
- 使用可靠消息模式
- 使用LCN框架解决分布式事物
- 阿里GTS框架解决分布式事物
传统模式Jta+Atomikos
传统项目中，比如项目中使用到多数据源的时候大多数采用jta+Atomikos解决分布式事务问题，jta+Atomikos底层是基于XA协议的两阶段提交方案。
XA协议:XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。Mysql 在这个XA事务中扮演的是参与者的角色，而不是协调者(事务管理器)。
JTA:JTA（java Transaction API）是JavaEE 13 个开发规范之一。java 事务API，允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序的JTA支持极大地增强了数据访问能力。事务最简单最直接的目的就是保证数据的有效性，数据的一致性
Atomikos:Atomikos TransactionsEssentials 是一个为Java平台提供增值服务的并且开源类事务管理器
演示jta+atomikos项目
分布式事务解决方案采用Atomikos 后台管理系统
两阶段提交协议
第一阶段：准备阶段
协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志，然后锁定资源，执行操作，但并不提交
第二阶段：如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放资源，如果任何一个参与者明确返回准备失败，则协调者会发送终止指令，参与者取消已经变更的事物，释放锁定的资源。三段提交协议
三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段：
询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。
准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功
提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致
2PC和3PC的区别
增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大
三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。
LCN框架简单介绍:
1.LCN客户端（发起方和参与方都必须要注册到事务协调者中） 建立一个长连接。
2.订单服务（发起方）调用库存服务接口（参与方）之前会向TxManager事务协调者创建一个事务的分组id。
3.订单服务（发起方）调用库存服务接口（参与方）的时候，会在请求头中存放该事务的分组id，给库存服务。
4.如果库存服务获取到请求头中有对应的事务分组id，库存服务业务逻辑代码执行完毕的，会采用假关闭，不会提交该事务。
5.参与方在什么时候提交事务。
答案：肯定在发起方 执行成功下。
订单服务（发起方）调用库存服务接口（参与方）之后，如果订单服务（发起方）执行没有问题的下，
订单服务（发起方）使用对应的事务分组id，通知给TxManager事务协调者，让后TxManager事务协调者在根据该事务分组id，通知给所有的参与方提交事务。
解答：长连接 好处减少宽带传输 弊端比较占内存。
“LCN并不生产事务，LCN只是本地事务的搬运工”
兼容 dubbo、springcloud、motan 框架，支持各种关系型数据库
LCN目前版本为4.0，官方文档:https://www.txlcn.org/
LCN底层实现原理:https://github.com/codingapi/tx-lcn/wiki/LCN原理
SpringCLoud客户端集成
Maven依赖信息
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>transaction-springcloud</artifactId>
<version>4.1.2</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>tx-plugins-db</artifactId>
<version>4.1.2</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>application.yml引入
tm:
manager:
url: http://127.0.0.1:8899/tx/manager/LCN基本配置代码
@Service
public class TxManagerTxUrlServiceImpl implements TxManagerTxUrlService {
@Value("${tm.manager.url}")
private String url;
@Override
public String getTxUrl() {
System.out.println("load tm.manager.url ");
return url;
}
}
@Service
public class TxManagerHttpRequestServiceImpl implements TxManagerHttpRequestService {
@Override
public String httpGet(String url) {
System.out.println("httpGet-start");
String res = HttpUtils.get(url);
System.out.println("httpGet-end");
return res;
}
@Override
public String httpPost(String url, String params) {
System.out.println("httpPost-start");
String res = HttpUtils.post(url, params);
System.out.println("httpPost-end");
return res;
}
}分布式事物案例
// 下单扣库存
@TxTransaction(isStart = true)
@Transactional
@GetMapping(value = "/addOrderAndStock")
public ResponseBase addOrderAndStock(int i) {
OrderEntity orderEntity = new OrderEntity();
orderEntity.setName("蚂蚁课堂永久会员充值");
orderEntity.setOrderCreatetime(new Date());
// 价格是300元
orderEntity.setOrderMoney(300d);
// 状态为 未支付
orderEntity.setOrderState(0);
Long commodityId = 30l;
// 商品id
orderEntity.setCommodityId(commodityId);
// 1.先下单，创建订单
int orderResult = orderMapper.addOrder(orderEntity);
System.out.println("orderResult:" + orderResult);
// 2.下单成功后,调用库存服务
ResponseBase inventoryReduction = stockFeign.inventoryReduction(commodityId);
// if (inventoryReduction.getRtnCode() != 200) {
// // 手动回滚事务
// }
int reuslt = 1 / i;
return setResultSuccess("下单成功!");
}使用@TxTransaction解决分布式事务 isStart true 是:是发起方 false 否:是参与方
同理生产者 同样配置集成即可，只需要把Transaction 中的isStart改为fasle即可。
