分布式事务_分布式事务传播行为有哪些-CSDN博客

本文链接：https://blog.csdn.net/Andy86869/article/details/88430069

事务是保证一组数据操作的完整性和一致性
分布式事务

事务的四中隔离级别

read uncommitted 最低级别，任何情况都无法保证
read committed 可避免脏读的发生
repeatable_read 可避免脏读、不可重复读的发生
Serializable可避免脏读、不可重复读、幻读的发生

事务的四个特性

原子性
在计算机程序中，原子性就是对一组数据的操作是一个整体不可分割的意思。
一致性
经典的转账说明，A给B10000块，那么A 账户少了 10000块，B账户多了10000块，不能出现B账户多了10000块，而A账户的金额没有变化
隔离性
还是那转账的例子说明，A给B 转账 10000 ，C给D 转账 50000，AB ，CD 这两组直接是没有关系的，是隔离的。
持久性
持久性就是持久化这样，也没什么可说的。

事务的七种传播行为

propagation_requeired
如果存在一个事务，则支持当前的事务，如果没有事务则开启一个新的事务
propagation_supports
如果存在一个事务，支持当前事务，如果没有事务，则非事务的执行，但是对于事务同步的事务管理器，propagation_supports 与不使用事务有少许不同
propagation_mandatory
如果存在一个事务，支持当前的事务，如果没有一个活动的事务，则抛出异常
propagation_requires_new
总是开启一个新的事务，如果一个事务已经存在，则将这个存在的事务挂起
propagation_never
总是非事务地执行，如果存在一个活动事务，则抛出异常
propagation_not_supported

总是非事务的执行，并挂起任何存在的事务

propagation_nested
如果一个活动的事务存在，则运行在一个嵌套的事务中，如果没有活动事务，则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

分布式事务
分布式事务是在分布架构，微服务的架构下出现的，分布式事务就是将多个节点的事务看成一个整体处理。
分布式事务一般有事务参与者，资源服务器，事务管理器等组成
分布式事务出现的场景有哪些 eg. 下订单，减库存，支付

分布式事务强调的不是事务，它依赖于每个单点的事务机制，它强调的是事务的分布式。到底如何解决分布式事务

实现思路

2PC 3PC，也说两段式，3段式事务
基于XA 的分布式事务
基于消息的最终一致性方案
TCC 编程是补偿事务(比较常用的一种分布式解决方案)

两段式事务 2PC
在这里插入图片描述
看图，首先是一个事务管理器，第一个阶段事务管理器先给两个资源管理器发送 prepare 命令，如果两个资源管理器的其中一个没有ready, 那么就要等待了，等两个资源管理器都给事务管理器回复 ready 命令，那么第一个阶段就完事了；接下来进入第二个阶段，事务管理器给两个资源管理器发送 commit 命令，如果两个资源管理器都接收到命令并提交了 committed
那么事务这一组事务OK，但是如果其中一个没有 committed ，那就出问题了。这个2PC 的分布式事务还有其他诸多的问题。

我们来看一下 3PC
三段式提交3PC
三段式事务就是在两段式事务的 预备和提交中间加了一层 "预" 状态，准备之前，给资源服务器发送一个预，问一下资源服务器，你们都准备好了吗，资源服务器回复：都准备好了，资源服务器就绪了，提交之前，在问一次，你们都准备好提交了吗，资源服务器回复：都准备好了了，事务管理器收到准备好了的确认后发生提交请求。

2PC 和 3PC 在正式分布式系统中一般不会使用

基于XA 的分布式事务
在这里插入图片描述
xa 的分布式事务是 2PC 的演进而来。

基于消息的一致性方案
如下图，加入A 是支付系统，B是订单系统，A 发送一个预备消息给 mq，mq 收到预备消息保存，并返回个A 系统说，我mq 已经收到你的预备消息了，你可以执行你的业务逻辑了，然后A系统开始执行本地事务，并发送给mq 提交消息，mq 收到A 系统的提交消息（此时支付系统已经支付了），mq 将消息发送给订单系统 B，说A系统已经支付了，你赶紧给我改订单状态，同时 mq 回调给 A 系统，让A 该干嘛干嘛。这里可能有人就要问了，如果B系统修改订单状态失败怎么办？对啊，这怎么办呢，其实实际中，再A 系统发送提交消息之前呢，可以另起一个线程，并让它挂起一下，挂起之后，去告诉B 系统，A这边马上就要提交了，你赶紧修改下订单状态吧。等B 修改完订单状态，A 就去提交支付，如果B 修改失败，A就在本地回滚了。
基于消息的一致性方案是属于强一致性的方案，一定是同时成功，或者同时失败，不会出现其他的情况，缺点就是 A 系统支付业务就会暂停，B 修改之前就会一直等待，但是一般是等不起的。后面我们来说说 TCC
在这里插入图片描述

TCC补偿性事务

T try ,C confirm ,C cancel
中文简单解释就是 : 尝试执行，确认操作，取消操作

在这里插入图片描述
假如上图的服务A 是扣减库存，服务B 是创建订单，以扣减库存创建订单这一业务流程来说一下 TCC
首先第一步 app 告诉事务协调器要启动一个事务了，然后就调用 try 接口，服务A try 接口扣减库存，服务B 创建订单,最终 app 收到 AB 两个的try 接口的执行结果，如果有一个失败了，app 告诉事务协调器，刚刚这个事务失败了，你调用 Cancel 接口吧；如果两个都成功了，那么 app 告诉事务协调器调用 Confirm 接口

TCC的核心思想是资源，最核心的就是在 Try 阶段，一定要把资源做好预留（加锁，加版本号，加分布式锁等方式，先把资源给占着），为什么一定要预留呢，不预留的话，在 Cancel 阶段就无法补偿了，也就违背了TCC设计的初衷。如果对于资源的掌控力度不够，不建议使用TCC，如果资源没办法做预留，没有乐观锁，没有状态等字段，没法预留也就没法用TCC

tcc 补偿性和基于消息的分布式事务表

基于消息的分布式事务是强一致性的，会存在浪费资源
因为会存在等待，唯独最大的好处就是强一致性，实际业务中，可能要去要对接支付宝支付，微信支付，银联支付等待，这种消息性的事务还是可以使用的
TCC 强调的是在 try 的阶段对资源做预留
TCC 在确认和取消阶段释放资源
如果是确认阶段，那么将资源删掉就行了，如果是取消阶段，那么我们需要将这些资源进行反向的补偿。
与消息性事务，TCC 的时效性高

开源的事务协调器

https://github.com/changmingxie/tcc-transaction