分布式事务-seata

2PC两阶段提交协议：

第一阶段：

• 1. 询问 协调者向所有参与者发送事务请求，询问是否可执行事务操作，然后等待各个参与者的响应。
• 2. 执行 各个参与者接收到协调者事务请求后，执行事务操作(例如更新一个关系型数据库表中的记录)，并将 Undo 和 Redo 信息记录事务日志中。
• 3. 响应 如果参与者成功执行了事务并写入 Undo 和 Redo 信息，则向协调者返回 YES 响应，否则返回 NO 响应。当然，参与者也可能宕机，从而不会返回响应

第二阶段：

commit：

• 1. commit 请求 协调者向所有参与者发送 Commit 请求。
• 2. 事务提交 参与者收到 Commit 请求后，执行事务提交，提交完成后释放事务执行期占用的所有资源。
• 3. 反馈结果 参与者执行事务提交后向协调者发送 Ack 响应。
• 4. 完成事务 接收到所有参与者的 Ack 响应后，完成事务提交。

中断事务：

在执行 Prepare 步骤过程中，如果某些参与者执行事务失败、宕机或与协调者之间的网络中断，那么协调者就无法 收到所有参与者的 YES 响应，或者某个参与者返回了 No 响应，此时，协调者就会进入回退流程，对事务进行回退。

• 1. rollback 请求 协调者向所有参与者发送 Rollback 请求。
• 2. 事务回滚 参与者收到 Rollback 后，使用 Prepare 阶段的 Undo 日志执行事务回滚，完成后释放事务执行 期占用的所有资源。
• 3. 反馈结果 参与者执行事务回滚后向协调者发送 Ack 响应。
• 4. 中断事务 接收到所有参与者的 Ack 响应后，完成事务中断。

2PC两阶段提交协议潜在问题：

• 1. 同步阻塞 参与者在等待协调者的指令时，其实是在等待其他参与者的响应，在此过程中，参与者是无法行其他操作的，也就是阻塞了其运行。 倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直阻塞下去。
• 2. 单点 在 2PC 中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞并一直占用事务资源，如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息(例如已等待 Prepare 响应的时长等)，所以也无法顺利处理上一个事务。
• 3. 数据不一致 Commit 事务过程中 Commit 请求/Rollback 请求可能因为协调者宕机或协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到 Commit/Rollback 请求，而其他参与者则正常收到执行了Commit/Rollback 操作，没有收到请求的参与者则继续阻塞。这时，参与者之间的数据就不再一致了。当参与者执行 Commit/Rollback 后会向协调者发送 Ack，然而协调者不论是否收到所有的参与者的 Ack，该事务也不会再有其他补救措施了，协调者能做的也就是等待超时后像事务发起者返回一个“我不确定该事务是否成功”。
• 4. 环境可靠性依赖 协调者 Prepare 请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应，那么在 2PC 中，协调者会等待一定时间，然后超时后，会触发事务中断，在这个过程中，协调者和所有其他参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。

Seata的四种模式

seata主要有以下四种模式

• AT
• TCC
• Saga
• XA

这里主要介绍ATT以及TCC

AT模式：

AT 模式是一种无侵入的分布式事务解决方案在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

阶段一：

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数

据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，

在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库

事务内完成，这样保证了一阶段操作的原子性。

第二阶段：

提交：

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一

阶段保存的快照数据和行锁删掉，完成数据清理即可。

回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方 式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务 数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一 致就说明有脏写，出现脏写就需要转人工处理（逆向生成SQL是指分析后转换成update语句执行）

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能

轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

TCC模式

特点：

• 1. 侵入性比较强， 并且得自己实现相关事务控制逻辑
• 2.在整个过程基本没有锁，性能更强

实现步骤：

TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法

TCC 三个方法描述：

• Try：资源的检测和预留；
• Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
• Cancel：预留资源释放；

Seata的三大角色

在 Seata 的架构中，一共有三个角色：

TC (Transaction Coordinator) - 事务协调者

维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器

定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器

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

其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端

Server端存存储模式

• file：(默认)单机模式，全局事务会话信息内存中读写并持久化本地文件root.data，性能较高(默认）
• db：（5.7+）高可用模式，全局事务会话信息通过db共享，相应性能差些
• redis：Seata-Server 1.3及以上版本支持,性能较高,存在事务信息丢失风险,请提前配置适合当前场景的redis持久化配置

配置db：

• 打开config/file.conf
• 修改mode="db"
• 修改数据库连接信息（URL\USERNAME\PASSWORD)
• 创建数据库seata_server
• 新建表： 可以去seata提供的资源信息中下载：\script\server\db\mysql.sql

代码中使用seata管理分布式事务只需要在方法上添加注解@GlobalTransactional