java之分布式事务

分布式事务

分布式事务

传统数据库事务

事务特性

原子性：A 事务中的所有操作，要么全部成功，要么全部失败 影响事务的操作，一般指的是增删改，也就是一个事务中，有多个增删改的SQL

一致性：C 事务开始前到事务结束后，数据状态需要一致 如 转账 李四给张三转200 李四余额+200，张三余额-200 支付 王五买了一个iphone12，支付了5500 王五余额-5500 订单状态，由 0 -> 1，0：未支付，1：已支付

隔离性：I 多个事务之间的操作相互隔离，互不影响 如 我这边转账，不影响你那么支付。反之亦然 隔离级别 读未提交：会产生脏读、幻读、不可重复读的问题 读已提交：会产生幻读、不可重复读的问题（oracle默认） 可重复读：会产生幻读的问题（mysql默认） 串行化：没有任何问题，但是相当于锁表，效率极低。所以这种方案不用 不同的隔离级别会产生不同的问题 脏读：一个事务读到了另一个事务没有提交的数据 不可重复读：同一个事务中，连续读取两次，得到结果不一样 幻读：事务操作看到前和看到后的结果不一致，就像出现了幻觉一样 1、在A事务中执行查询，看到两条数据 2、在B事务中执行增加操作，成功插入一条数据 3、在A事务中执行修改操作，发现修改影响行数为3行 演示：设置事务隔离级别 -> 开启事务 -> 操作 -> 提交事务

持久性：D 事务一旦提交，则永久的保存到磁盘，不可逆

事务控制

JDBC：Connection ​ Mybatis：SqlSession ​ Spring：基于运行时异常的声明式事务

分布式事务

概述：在分布式环境下，出现的事务问题

种类：跨服务

多服务多数据库：

多服务单数据库：

总体来说，就是出现了多个数据库连接

案例：

下单付款：

1、创建新订单 2、扣减商品库存 3、从用户账户余额扣除金额

对比传统事务：

分布式理论

CAP定理

是一个分布式系统架构；

三个指标

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。

Partition tolerance （分区容错性）：Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区；Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。容忍出现分区的问题

分区：

在分布式环境下，这三个指标不可能同时做到，且P是一定要保证的（为什么？因为网络是不可靠的。客户因素，没办法避免）

CP：在一定时间内，等待集群节点进行数据同步后，对外提供访问

AP：在任何时间内，都对外访问，但是得到的数据可能不一样

CA：反证法，不能同时出现 多个节点要想数据一致，需要时间同步。那么在这个时间内，一定不能对外访问，所以A不成立。如果可以对外访问，那么数据就不一致，所以C就不成立了； 如果一定要满足CA，那就没有P，也就不是分布式环境了，是单节点。

BASE理论

概述： 对CAP的一种补充 放弃强一致性，追求最终一致性

三个思想：

1、Basically Available（基本可用） ​ 分布式系统在出现故障时，允许损失部分可用性，即保证核心可用； ​ 譬如电商大促，为了应对大流量，暂时停止注册服务，这时注册服务就不可用，但是整个系统是可用的，所以叫基本可用。

2、Soft State（软状态）

在一定时间内，允许出现中间状态，比如临时的不一致状态；

比如订单状态：待付款、已付款待发货、已发货、已签收、已结束。

3、Eventually Consistent（最终一致性） ​ 虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

分布式事务的解决思路 1、AP模式：最终一致性 各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。 譬如：增加了一条数据，后面有操作失败了，那么，补偿措施只需要把增加的那条数据删除即可 因为子事务提交了，那么提交后的状态是一个中间状态，也就是软状态。 2、CP模式：强一致性 各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。 事务执行过程中，会锁定操作的资源，那么这个资源暂时是不可用的。所以整个系统是基本可用。 子事务：分支事务 全局事务：事务协调者，用来监控和通知各个分支事务

Seata

seata架构

TC (Transaction Coordinator)： 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚； 监控和通知各个事务，包括分支事务和全局事务。

TM (Transaction Manager) ： 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务； 执行事务。

RM (Resource Manager)： 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

XA模式

是一个X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，历史悠久，几乎主流关系型数据库都支持。

原理都是基于两阶段提交：

一阶段： 事务协调者通知每个事务参与者执行本地事务； 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁。

二阶段： 事务协调者基于一阶段的报告来判断下一步操作： 如果一阶段都成功，则通知所有事务参与者，提交事务； 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务。

正常情况：

异常情况：

seata的XA模型：（XA中的重点）

优点： 事务的强一致性，满足ACID原则； 常用数据库都支持，实现简单，并且没有代码侵入。

缺点： 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差； 依赖关系型数据库实现事务。

使用：

1、配置文件

seata:
    data-source-proxy-mode: XA

（注意：每个微服务都需要配置）

2、全局事务开始方法标记注解：@GlobalTransactional

AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

seata的AT模式(重点记)：

阶段一RM的工作： 1、注册分支事务 2、记录undo-log（数据快照） 3、执行业务sql并提交 4、报告事务状态

阶段二RM的工作： 1、删除undo-log即可 一阶段都成功，则提交，删除undo-log； 一阶段有失败，则回滚，恢复undo-log日志，删除undo-log。

优点： 不会死锁 最终一致性

部署Seata-TC服务关键注解：

在分布式事务的入口方法上增加一个注解：@GlobalTransactional

支持的模式 1、XA 2、AT 3、SAGA：适用于长连接 4、TCC：1、Try....Confirm...Cancel 一阶段：预留资源 二阶段：提交或回滚 2、手写补偿逻辑