> 关于分布式事务要清楚，Seata是在分布式场景下的一种解决方案，也是一种实现，我们不仅仅可以使用seata来解决还能够自行去解决，最终的目的都是在多个微服务下做同一个业务的时候，每个微服务要做到`同时成功同时失败`，那么这个就是分布式事务 ## 1.本地事务 1. 本地事务，也就是传统的单机事务。在传统数据库事务中，必须要满足四个原则： - 原子性：事务中所有操作要么全部成功，要么全部失败 - 一致性：要保证数据库内部完整性的约束 - 隔离性：不同事务要做分离 - 持久性：对数据进行持久化操作，通俗就是将数据保存在硬盘 ## 2.分布式事务 1. 分布式事务，就是指不是在单个服务或单个数据库架构下，产生的事务 - 跨数据源的分布式事务 - 跨服务的分布式事务 2. 在数据库水平拆分、服务垂直拆分之后，一个业务操作通常要跨多个数据库、服务才能完成。例如电商行业中比较常见的下单付款案例 - 创建新订单 - 扣减商品库存 - 从用户账户余额扣除金额 3. 完成上面的操作需要访问三个不同的微服务和三个不同的数据库。  基于此以上的操作步骤：三件事情看做一个"业务"，要满足保证“业务”的原子性，要么所有操作全部成功，要么全部失败，不允许出现部分成功部分失败的现象，这就是分布式系统下的事务了。此时ACID难以满足，这是分布式事务要解决的问题 ## 3. CAP定理 1. Consistency（一致性）用户访问分布式系统中的任意节点，得到的数据必须一致。 2. Availability（可用性）用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝 3. Partition tolerance （分区容错性）用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝；在集群出现分区时，整个系统也要持续对外提供服务 ### 3.1. 解决分布式事务的思路 1. AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。（`互联网业务`） 2. CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。（`金融业务`） ### 3.2. 矛盾之处  >如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。 >如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。 ## 4. 基于此引入出BASE理论 > BASE理论是对CAP的一种解决思路，包含三个思想： 1. Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。 2. Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。 3. Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。 ## 5. Seata的架构-事务管理中三个重要角色 - TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。 - TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。 - RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 ## 6. Seata基于上述架构提供了四种不同的分布式事务解决方案： >无论哪种方案，都离不开TC，也就是事务的协调者。 1. XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入 2. TCC模式：最终一致的分阶段事务模式，有业务侵入 3. AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式 4. SAGA模式：长事务模式，有业务侵入 ## 7. XA模式 >XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。 1. 正常情况  2. 异常情况  3. 一级段提交： - 事务协调者通知每个事物参与者执行本地事务 - 本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁 4. 二阶段提交： - 事务协调者基于一阶段的报告来判断下一步操作 - 如果一阶段都成功，则通知所有事务参与者，提交事务 - 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务 ### 7.1. 基于Seata的XA模型 > Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图： > - TC - 事务协调者 > - TM - 事务管理器 > - RM - 资源管理器  1. RM一阶段的工作： - ① 注册分支事务到TC - ② 执行分支业务sql但不提交 - ③ 报告执行状态到TC 2. TC二阶段的工作： - TC检测各分支事务执行状态 - 如果都成功，通知所有RM提交事务 / 如果有失败，通知所有RM回滚事务 3. RM二阶段的工作： - 接收TC指令，提交或回滚事务 ### 7.2. XA模式的优缺点 1. XA模式的优点是什么？ - 事务的强一致性，满足ACID原则。 - 常用数据库都支持，实现简单，并且没有代码侵入 2. XA模式的缺点是什么？ - 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差；如果一阶段有大量的事务等待，那就是资源浪费了 - 依赖关系型数据库实现事务 ## 8. AT模式 > AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。 ### 8.1. Seata的AT模型（Seata默认的模式）  1. 阶段一RM的工作： - 注册分支事务 - 记录undo-log（数据快照） - 执行业务sql并提交 - 报告事务状态 2. 阶段二提交时RM的工作： - 删除undo-log即可 3. 阶段二回滚时RM的工作： - 根据undo-log恢复数据到更新前 4. 流程梳理  |id| num | |--|--| | 1 | 100 | - 现在数据库有一个库存表，数量为100 - 其中一个事务执行了update的num-1的请求了，并且直接本地事务提交，此时将元数据做了一次快照，提交报告事务状态 - TC判断是否可以提交，可以则就提交进行数据的提交，并将快照删除；如果不能提交，就读取快照进行数据恢复，删除快照 ### 8.2. AT与XA的区别 1. XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。 2. XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。 3. XA模式强一致；AT模式最终一致 ### 8.3. AT模式下的脏写问题 1. 在多线程并发访问的情况下，有可能出现在一阶段提交，还未到二阶段的时候，又来一个线程将数据修改了，如果线程1出现了问题导致数据回滚，则线程2这不就白忙乎了  2. 解决办法就是利用TC（事务协调者）加一个全局锁，注意看这里不是数据库的锁！`还会出现的问题就是，并非stata所管理的服务如线程1的一阶段提交后线程2进行数据的更新`  3. 关于`非stata所管理的服务如线程1的一阶段提交后线程2进行数据的更新；并且线程1进行了数据的回滚`的解决方案，当然这样的场景也是非常小的，可以在代码层面所避免这样的情况，即使在少也不能不处理；说白了解决方案就是， - 在线程1的二阶段提交的时候，先查看阶段一修改后的数据和二阶段查询数据库字段的数据是否相同， - 如果相同才能回滚，否则可以发送消息提醒，人工介入  ### 8.4. AT模式的优缺点 1. AT模式的优点： - 一阶段完成直接提交事务，释放数据库资源，性能比较好 - 利用全局锁实现读写隔离 - 没有代码侵入，框架自动完成回滚和提交 2. AT模式的缺点： - 两阶段之间属于软状态，属于最终一致 - 框架的快照功能会影响性能，但比XA模式要好很多 ## 9. TCC模式（不需要加锁，但是不是所有的业务都适合TCC模式，适用于余额扣减的情况） > TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法： 1. Try：资源的检测和预留； 2. Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。 3. Cancel：预留资源释放，可以理解为try的反向操作。 ### 9.1. 流程分析 1. 举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。 - 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30  余额充足，可以冻结  此时，总金额 = 冻结金额 + 可用金额，数量依然是100不变。事务直接提交无需等待其它事务。 - 阶段二（Confirm)：假如要提交（Confirm），则冻结金额扣减30 确认可以提交，不过之前可用金额已经扣减过了，这里只要清除冻结金额就好了：  此时，总金额 = 冻结金额 + 可用金额 = 0 + 70 = 70元 - 阶段二(Canncel)：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30 需要回滚，那么就要释放冻结金额，恢复可用金额：  ### 9.2. Seata的TCC模型 >Seata中的TCC模型依然延续之前的事务架构，如图：  1. TCC的优点是什么？ - 一阶段完成直接提交事务，释放数据库资源，性能好 - 相比AT模型，无需生成快照，无需使用全局锁，性能最强 - 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库 2. TCC的缺点是什么？ - 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦 - 软状态，事务是最终一致 - 需要考虑Confirm和Cancel的失败情况，做好`幂等`处理；因为会重试，所以要幂等 #### 9.2.1. 事务悬挂和空回滚 > 空回滚：当某分支事务的try阶段`阻塞`时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。  执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。 > 业务悬挂 ： 对于已经空回滚的业务，之前被阻塞的try操作恢复，继续执行try，就永远不可能confirm或cancel ，事务一直处于中间状态，这就是业务悬挂。执行try操作时，应当判断cancel是否已经执行过了，如果已经执行，应当阻止空回滚后的try操作，避免悬挂 #### 9.2.2. 实现TCC模式 > 解决空回滚和业务悬挂问题，必须要记录当前事务状态，是在try、还是cancel？需要记录就要有一张数据库表来记录 1. 思路分析，这里我们定义一张表：下面冻结金额的`unsigned` 表示不能为负数 ```sql CREATE TABLE `account_freeze_tbl` ( `xid` varchar(128) NOT NULL, `user_id` varchar(255) DEFAULT NULL COMMENT '用户id', `freeze_money` int(11) unsigned DEFAULT '0' COMMENT '冻结金额', `state` int(1) DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel', PRIMARY KEY (`xid`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT; ``` `xid`：是全局事务id `freeze_money`：用来记录用户冻结金额 `state`：用来记录事务状态 2. 操作步骤 - Try业务： - 记录冻结金额和事务状态到account_freeze表 - 扣减金额表可用金额 - Confirm业务： - 根据xid删除account_freeze表的冻结记录 - Cancel业务 - 修改account_freeze表，冻结金额为0，state为2 - 修改金额表，恢复可用金额 - 如何判断是否空回滚？ - cancel业务中，根据xid查询account_freeze，如果为null则说明try还没做，需要空回滚 - 如何避免业务悬挂？ - try业务中，根据xid查询account_freeze ，如果已经存在则证明Cancel已经执行，拒绝执行try业务 ## 10. Seata的SAGA模式（一般适用于`跨公司`业务的接口调用） > 在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。  1. Saga也分为两个阶段： - 一阶段：直接提交本地事务 - 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚 ### 10.1 SAGA模式的优缺点 1. 优点 - 事务参与者可以基于事件驱动实现异步调用，吞吐高 - 一阶段直接提交事务，无锁，性能好 - 不用编写TCC中的三个阶段，实现简单 2. 缺点 - 软状态持续时间不确定，时效性差 - 没有锁，没有事务隔离，会有脏写 ## 11. 总结 | | XA | AT | TCC|SAGA| |--|--|--|--|--| |一致性 | 强一致 | 弱一致 | 弱一致 | 最终一致 | | 隔离性 |完全隔离 | 基于全局锁隔离 | 基于资源预留隔离 | 无隔离 | |代码侵入 | 无 | 无 | 有，需要编写三个接口 | 有，要编写状态机和补偿业务 | | 性能 | 差 | 好 | 非常好 | 非常好 | | 场景| 对一致性，隔离性有高要求的业务 | 基于关系型数据库的大多数分布式事务场景都可以 | 对性能要求高的事务，有非关系型数据库要参与事务的 | 业务流程长，业务流程多，参与者包含其他公司或遗留系统服务，无法提供TCC模式要求的三个接口 | ## 12. 高可用 > Seata的TC服务作为分布式事务核心，一定要保证集群的高可用性。 ### 12.1. 高可用架构模型 1. 搭建TC服务集群非常简单，启动多个TC服务，注册到nacos即可。 2. 但集群并不能确保100%安全，万一集群所在机房故障怎么办？所以如果要求较高，一般都会做异地多机房容灾。 3. 比如一个TC集群在上海，另一个TC集群在杭州：  4. 微服务基于事务组（tx-service-group)与TC集群的映射关系，来查找当前应该使用哪个TC集群。当SH集群故障时，只需要将vgroup-mapping中的映射关系改成HZ。则所有微服务就会切换到HZ的TC集群了。