JAVA：本地事务与分布式事务技术实践与挑战

拾荒的小海螺

已于 2023-12-25 11:10:37 修改

阅读量403

点赞数

分类专栏： JAVA 文章标签： java 本地事务 seata

于 2021-09-03 09:08:19 首次发布

本文链接：https://blog.csdn.net/lishangke/article/details/120050405

版权

37 篇文章 1 订阅

订阅专栏

随着企业规模的扩大和业务复杂性的增加，分布式系统的应用变得越来越普遍。在这样的环境中，事务处理变得尤为重要，而本地事务和分布式事务则成为了两个不可忽视的关键概念。本文将深入探讨本地事务和分布式事务的技术实践，探讨其优势、挑战以及解决方案。

数据库事务四大特性： Atomic原子性、Consistency一致性、Isolation隔离性和Durability持久性，简称就是ACID

隔离级别从低到高分为四级：
在这里插入图片描述

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

Read committed（读已提交）
一个事务可以读取另一个已提交的事务，多次读取会造成不一样的结果，此现象称为不可重复读问题，Oracle和SQL Server的默认隔离级别。

@Transactional(isolation = Isolation.READ_COMMITTED)

Repeatable read（可重复读取）
该隔离级别是MySql默认的隔离级别，在同一个事务里，Select的结构是事务开始时时间点的状态，因此，同样的Select操作读到的结果是一致的，但是会出现幻读现象。Mysql的InnoDb引擎可以通过next-key locks机制来避免幻读。

@Transactional(isolation = Isolation.REPEATABLE_READ)

Serializable（串行化）
在该隔离级别下事务都是串行顺序执行的。Mysql数据库的InnoDb引擎会给读操作隐式加一把共享锁。从而避免了脏读，不可重复读和幻读的问题。

@Transactional(isolation = Isolation.SERIALIZABLE)

解决方法：采用代理对象来调用事务方法

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

开启AspectJ动态代理，没有接口也可以创建动态代理

@EnableAspectJAutoProxy(exposeProxy = true)

通过AopContext就可以调用对象内事务方法。

WareSkuService skuService = (WareSkuService)AopContext.currentProxy();
skuService.GetSkuHasStock(null);

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

一致性（Consistency）
在分布式系统中的所有数据备份，在同一时刻是否有同样的值(等同于所有节点访问同一份最新的数据副本)
分布式实现一致性算法：
http://thesecretlivesofdata.com/raft/
可用性（Availability）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
分区容错性（Partition tolerance）
大多数分布式系统都分布在多个子网格。每个子网格就叫做一个区。分区容错的意思是，区间通信可能失败。比如，一台服务器在中国，另外一台服务器在美国，这就是两个区，他们之间可能无法通信。

备注：这三个要素最多只能同时实现两点(CP、AP),不可能三者兼顾。

是对CAP理论的延伸，就是即使无法做到强一致性，也可以采用弱一致性，即最终一致性。

基本可用
指的是分布式系统出现故障时，允许损失部分可用性(如响应时间)，基本可用不等价于系统不可用。
响应时间上的损失，引擎响应延迟。
网站购物高峰期，页面的降级引导。
软状态
指的是允许系统存在中间状态，而该中间状态不会影响到整个系统的可用性。分布式存储一般一份数据有多个副本，允许不通副本同步的延时就是软状态的体现。mysql replication的异步也是一种体现。
最终一致性
指的是系统中所有数据副本经过一定时间后，最终能够达到一致的状态，弱一致性和强一致性想法。最终一致性是弱一致性的特性情况。

2PC模式
数据库二阶提交,一阶预备提交，二阶提交数据，简称XA
柔性事务-TCC事务补偿协议
柔性事务，遵循BASE理论，实现最终一致性。
一阶段prepare行为。
二阶段commit行为。
三阶段rollback行为。
比较典型的事务：
由阿里云提供的Seata
http://seata.io/zh-cn/docs/user/quickstart.html
柔性事务-最大努力通知方案
不一定通知成功，但会提供可查询接口进行核对。
当前方案，可以结合MQ来实现。
案例（银行通知，商户通知，支付宝支付成功异步调用等）
柔性事务-可靠消息+最终一致性
实现业务处理服务在业务提交之前，向MQ实时消息服务请求发送消息。实时消息只记录消息数据，而不是真真的发送。业务处理服务在业务提交之后，向实时消息服务确认发送，只有在确认收到发送指令后，才会真正的发送实时消息。