【Seata】_01 分布式事务基础知识和常见的解决方案

本地事务

单一的数据库事务，ACID由数据库直接提供

分布式事务

一个服务调用操作两个数据库；
多个服务操作同一个数据库；
多个服务操作多个数据库；
分布式事务无法由数据库保证

Seata 分布式事务解决方案

Seata提供AT/TCC/SAGA/XA事务模式。AT模式是阿里首推，本文主要基于AT学习
官网
源码

三大角色

TC（Transaction Coordinator）：事务协调者
维护全局和分支事务状态，驱动全局事务提交或回滚
TM（Transaction Manager）: 事务管理器
定义全局事务的范围，开始全局事务、提交或回滚全局事务
RM（Resource Manager）：资源管理器
管理分支事务处理的资源，与TC交谈注册分支事务和报告分支事务状态，并驱动分支事务提交或回滚
其中，TC为单独部署的Server，TM和RM为嵌入到应用中的Client

二阶段提交协议

常见分布式解决方案
1、seata 阿里分布式事务框架
2、消息队列
3、saga
4、XA
他们有一个共同点，都是"两阶段（2PC）。"两阶段"是指完成整个分布式事务，划分成两个步骤完成。
实际上，这四种常见的分布式事务解决方案，分别对应着分布式事务的四种模式：AT、TCC、Saga、XA；
四种分布式事务模式，都有各自的理论基础，分别在不同的时间被提出；每种模式都有它的适用场景，同样每个模式也都诞生有各自的代表产品；而这些代表产品，可能就是我们常见的（全局事务、基于可靠消息、最大努力通知、TCC）
我们会分别来看4种模式（AT、TCC、Saga、XA）的分布式事务实现.
在看具体实现之前，先讲下分布式事务的理论基础

分布式事务理论基础

因为3PC实现非常困难。市面上一般都是2PC：两阶段提交协议，

2PC

分为两个阶段：Prepare和Commit

Prepare：提交事务请求

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

Commit：执行事务提交

正常提交

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

中断事务

Prepare过程中某些参与者执行事务失败、宕机或与协调者之间的网络中断，那么协调者就无法收到所有参与者的 YES响应，或者某个参与者返回了 No响应在执行
此时，协调者就会进入回退流程，对事务进行回退。
1.rollback请求：协调者向所有参与者发送 Rolback 请求
2.事务回滚：参与者收到 Rollback后，使用Prepare 阶段的 Undo 日志执行事务回滚，完成后释放事务执行期占用的所有资源
3.反馈结果：参与者执行事务回滚后向协调者发送Ack响应
4.中断事务：接收到所有参与者的 Ack 响应后，完成事务中断

2PC问题

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

Seata分布式事务不同模式原理

AT模式（auto transcation）

用户只关注自己的业务SQL，用户的业务SQL作为一阶段，Seata会自动生成事务的二阶段提交和回滚操作

AT模式如何做到对业务的无侵入：
一阶段：Seata 会拦截"业务SQL"，首先解析SQL语义，找到"业务SQL"要更新的业务数据，在业务数据被更新前，将其保存成"before image"，然后执行“业务SQL"更新业务数据，在业务数据更新之后，再将其保存成"after image"，最后生成行锁（此时这条数据对外不可见）。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性

二阶段提交：

二阶段回滚：
Seata 就需要回滚一阶段已经执行的"业务SQL"，还原业务数据。回滚方式便是用"before image"还原业务数据；但在还原前要首先要校验脏写，对比"数据库当前业务数据"和"after image"，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理

TCC

TCC模式需要用户根据自己的业务场景实现 Try、Confimm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。很像事务消息，侵入性比较强，而且要自己实现事务控制逻辑，优点是没加锁，性能更强

可靠消息最终一致性方案

RocketMq之事务消息实现原理
这个文章没有提到的是如果消费者这边没有成功消费MQ会让他重试，但是还存在一个问题，消费者如果事务失败回滚怎么处理？继续给生产者发送事务消息？