事务

最新推荐文章于 2024-10-08 21:30:52 发布

饮酒知冷暖

最新推荐文章于 2024-10-08 21:30:52 发布

阅读量94

点赞数

分类专栏：数据库文章标签： java spring 数据库分布式

本文链接：https://blog.csdn.net/qq_35406115/article/details/117046450

版权

数据库专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1 事务基础

1 事务的四大特性

ACID,
A(atomicity):原子性
C(consistency)：一致性
I(isolation)：隔离性
D(durability)：持久性

2 事务的隔离性问题

脏读：事务中读到另一事务未提交回滚的数据
不可重复读：多次查询中有多次事务的提交，多次查询读取到数据不一致
幻读/虚读：事务中多次查询，后查询出现了前次查询未出现的数据

3 事务的隔离级别及解决的隔离性问题

Serializable（可串行化）：解决幻读，效率低，超时、锁竞争
Repeatable Read（可重读）：解决脏读，不可重复读
Read Committed（读取提交内容）：解决脏读
Read Uncommitted（读取未提交内容）：均为解决

详阅 https://blog.csdn.net/weisong530624687/article/details/90075063

2 spring事务传播属性

propagation_required
如果当前没有事务，则新建一个事务，如果当前有事务则加入到这个事务中去
propagation_required-new
创建一个新事务，如果当前存在事务则把当前事务挂起
propagation_suppotes
支持当前事务，如果没有事务则以非事务方式执行
propagation_not-suppoted
以非事务方式执行，如果存在事务则将当前事务挂起
propagation_mandatory
使用当前事务，如果当前没有事务，则抛出异常
propagation_never
不适用事务，如果存在事务，则抛出异常
propagation_nested
如果当前存在事务，则嵌套在事务中执行，如果没有事务则新建一个事务，在事务中嵌套执行

3 spring事务失效场景

非public权限修饰
非Spring容器管理的bean
注解修饰的方法被类内部方法调用
异常类型非RuntimeException
捕获异常后，却未抛出异常
事务传播行为设置异常
数据库存储引擎不支持事务

详阅： https://mp.weixin.qq.com/s/Vhr07lCfGMHDzQc8eYgYkQ

4 分布式事务

分布式事务模型
TCC 模型：TCC-Transaction、Hmily
TCC事务解决方案本质上是一种补偿的思路，它把事务运行过程分成try、confirm/cancel 两个阶段，每个阶段都由业务代码来控制。需要注意的是，TCC事务和2pc的思想类似，但与2pc实现不同，TCC不再是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，并且也并没有全局事务来把控整个事务逻辑。
实现过程：
try：完成所有业务检查（一致性），预留业务资源。
confirm：确认执行业务操作，只使用try阶段预留的业务资源。
cancel：取消try阶段预留的业务资源

XA 模型：Sharding Sphere、MyCAT
xa是个规范，根据这个思想衍生二阶段提交协议和三阶段提交协议。
XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。
资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。
事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务中的资源管理器进行通信。
应用程序：定义事务的边界，指定全局事务中的操作。

  2PC 模型：raincat、lcn
  二阶段提交是分布式事务的重要的一个关键点，二阶段提交协议包含了两个阶段：第一阶段（也称准备阶段）和第二阶段（也称提交阶段）
  
  MQ 模型：RocketMQ
消息一致性方案是通过消息中间件保证上下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，下游应用向消息系统订阅该消息，收到消息后执行相应操作。本质上是依靠消息的重试机制，达到最终一致性。消息驱动的缺点是：耦合度高，需要在业务系统中引入MQ，导致系统复杂度增加。

  BED 模型：Sharding Sphere
柔性事务是对XA协议的妥协和补偿，它通过对强一致性要求的降低，已达到降低数据库资源锁定时间的效果。柔性事务的种类很多，可以通过各种不同的策略来权衡使用。
一阶段提交 + 补偿 ：最大努力送达（BED）
最大努力送达，是针对于弱XA的一种补偿策略。它采用事务表记录所有的事务操作SQL，如果子事务提交成功，将会删除事务日志；如果执行失败，则会按照配置的重试次数，尝试再次提交，即最大努力的进行提交，尽量保证数据的一致性，这里可以根据不同的业务场景，平衡C和A，采用同步重试或异步重试。
这种策略的优点是无锁定资源时间，性能损耗小。缺点是尝试多次提交失败后，无法回滚，它仅适用于事务最终一定能够成功的业务场景。因此BED是通过事务回滚功能上的妥协，来换取性能的提升。

  Saga 模型：ServiceComb Saga
Saga事务模型又叫做长时间运行的事务（Long-running-transaction）, 它是由普林斯顿大学的H.Garcia-Molina等人提出，它描述的是另外一种在没有两阶段提交的的情况下解决分布式系统中复杂的业务事务问题。你可以在这里看到 Sagas 相关论文。
我们这里说的是一种基于 Sagas 机制的工作流事务模型，这个模型的相关理论目前来说还是比较新的，以至于百度上几乎没有什么相关资料。
该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。


【spring cloud采取分布式事务框架】
采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。
TX-LCN 主要有两个模块，Tx-Client(TC) Tx-Manager(TM). TC作为微服务下的依赖，TM是独立的服务。
LCN 采用3PC+TCC补偿机制