分布式事务Seata

1. 分布式事务

1.1 简介

本地事务–ACID

分布式事务

• 跨数据源
• 跨服务

1.2 CAP理论-BASE理论

CAP理论

BASE理论–对CAP的一种解决思路

• Basically Available（基本可用）：分布式系统出现问题的时候，允许损失部分可用，保证核心是可用的
• Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致的状态
• Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是软状态结束之后，最终要到达数据一致

解决分布式事物的思路

• AP模式：各个事务分别执行和提交，允许出现结果不一致，然后使用补救措施，实现最终的一致性

• CP模式：各个事务执行后相互等待，同时提交，同时回滚，达成强一致性，存在问题–事务在等待的过程中，处于弱可用状态

  需要事务协调者 TC (Transaction Coordinator)

  ​ 无论使用上面哪种模式，子系统之间需要进行通信，协调事务的状态，需要一个事务的协调者

2. Seata

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

Seata | Seata

微服务全景图

2.1 三种角色

有关联的分支事务在一起称作全局事务

2.2 四种方案

Seata提供了四种不同的分布式事务解决方案：

• XA模式：强一致性分阶段提交事务模式，牺牲了一定的可用性，无业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，是Seata的默认模式
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• SAGA模式：长事务模式，有业务侵入

2.2.1 XA模式

原理

Seata的XA就是对数据库XA模式进行了一层封装

优缺点

2.2.2 AT模式

原理

XA和AT模式的区别

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源
• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚
• XA模式强一致；AT模式最终一致

AT模式中 所有的记录快照和删除快照等操作都由框架完成

AT模式的脏写问题

引入 全局锁

优缺点

2.2.3 TCC模式

非关系型数据库也能操作

三个阶段

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。

• Try：资源的检测和预留
• Confirm：完成资源操作业务；要求Try成功Confirm一定要成功
• Cancel：预留资源释放，可以理解为try的反向操作

原理

资源预留

工作模型图

优缺点

幂等性

接口幂等性是指对于同一个请求，无论调用多少次，结果都是一致的。具体来说，就是在同一个时间段内，对于同一个请求，无论发送多少次，其最终的结果和影响都是相同的。

接口的幂等性能够保证系统的数据一致性和稳定性，避免了重复操作带来的不良影响。在实际开发中，常见的保证接口幂等性的方式包括以下几种：

1. Token 机制：通过为每个请求生成唯一的 Token 标识，并将其保存在服务端，当请求到达服务端时，先检查 Token 是否已经被使用过，如果已经被使用，则返回上一次请求的结果，否则执行请求并更新 Token。

2. 数据库乐观锁：在数据库中使用乐观锁机制，即在请求中携带版本号或者时间戳等信息，服务端在执行请求前先校验版本号或者时间戳是否一致，如果一致则执行请求，否则返回异常。

3. 请求参数校验：通过请求参数的校验机制，例如校验请求的必填项、参数类型、参数范围等，可以避免恶意请求或者重复请求对系统造成的影响。

总之，接口幂等性是保证系统稳定性和数据一致性的重要机制之一，开发者需要针对具体业务场景选择合适的幂等性保证策略，并在实现时考虑异常情况和多线程并发访问等问题。

空回滚-业务悬挂

接口

2.2.4 SAGA模式

2.3 四种模式对比

​

3. Seata高可用