分布式事务介绍

分布式事务介绍

什么是分布式事务

我们来想象一个场景，现在有一个微服务架构的电商系统，其中包含了订单服务、库存服务
他们分别部署在不同的服务器上，连接的也是不同的数据库。（以下的操作不考虑复杂情况）
现在用户对商品进行购买操作，我们要做两件事：

1.调用订单服务====> 针对用户下单的商品进行订单生成入库

2.调用库存服务====> 针对该商品进行库存削减

假如我们的系统是单体架构：也就是说所有的服务都在一个项目中(最原始的方式)，那么解决办法非常简单，只需要把这两个操作加入到一个本地事务中即可。比如：

@Transactional(RollbackFor=Exception.class)
public boolean buy(){
	//调用订单方法
	//调用库存方法
}

这样便可以保证两个sql,要么同时成功，要么同时失败。
但是如果在分布式系统中，就比较麻烦。因为两个sql实际上连接的是不同的数据库，如果订单生成成功，但是库存削减失败。那么整个系统将会变成这样（不一致状态）：

所以引出了分布式事务的概念：

分布式事务用于在分布式系统中保证不同节点之间的数据一致性。
分布式事务的实现有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。

分布式事务的解决方式

2PC

XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现，这里我们介绍两阶段提交的过程。
2PC中包含着两个角色：事务协调者和事务参与者

1. 第一阶段：

事务协调者会发送预处理请求===> 多个事务参与者

参与者接到请求后，每一个节点会各自执行与事务有关的数据更新
   ====> 如果本地执行成功，会向事务协调者返回“完成”消息。而且并不会提交事务(no commit)。
   ====> 如果本地执行失败，会向事务协调者返回"失败"消息。
当事务协调者接到了【所有参与者】的返回消息，整个分布式事务将会进入第二阶段。

全部成功的情况图：

部分失败的情况图：

2. 第二阶段：

• 如果事务协调节点收到的都是正向返回，那么它将会向所有事务参与者发出Commit请求。

多个事务参与者接到Commit请求之后，该节点会各自进行本地的事务提交，并释放锁资源。返回“完成”消息。
	一次分布式事务到此结束。

• 如果事务协调节点收到的包含失败返回,事务协调节点会向所有的事务参与者发送Abort请求。

多个事务参与者接收到abort请求后，会执行本地的回滚操作(rollback)。分布式事务结束
   原因： 因为某个事务参与者反馈了失败消息，说明该节点的本地事务执行不成功，其他节点也必须回滚。

结论

2PC看似解决了分布式事务，但是其实存在着缺点：
1.我们假设在第一阶段/第二阶段的时候，协调者发送请求，但是参与者迟迟没有回应，那么协调者就只能等着。这是性能问题。
2.假设第二阶段协调者发送了commit请求，因为网络原因部分参与者没有收到请求，那么其实会出现数据不一致的情况。
3.再假设协调者在过程中突然挂了。那么参与者收不到请求 会一直处于一个中间状态，不提交也不回滚。

TCC

Seata的AT模式

Seata是阿里研发的分布式事务框架，有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式
官网地址Seata官网点击这里

AT模式介绍:

AT模式也是基于二阶段提交的演变，这里贴一张官网的图：

我们可以看到：

- 一阶段会进行事务提交

（what?? 直接就提交了?? ）其实我们仔细看 这句话
【业务数据】和【回滚日志】一起提交，也就是说：在提交事务之前，需要将数据进行一个快照，记录下来。一会万一出现错误，好使用这个记录，进行回滚
那么官网已经给出了例子，这里不多赘述：点击这里查看官网过程描述

- 二阶段：

如果执行成功，立即返回。并且使用异步任务，把undo_log(回滚记录)删掉。
如果执行失败，那么需要依据之前记录的undo_log,进行数据补偿。

等等…略