Seate分布式事务解决⽅案
Seata是阿⾥开源的⼀个分布式事务框架。
Seata主要有两种分布式事务实现⽅案，AT及TCC
AT模式主要关注多 DB 访问的数据⼀致性，当然也包括多服务下的多 DB 数据访问⼀致性问题
微服务在哪里TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调⽤的⼀致性问题
AT模式/MT模式
Seata AT模式是基于XA事务演进⽽来的⼀个分布式事务中间件，XA是⼀个基于数据库实现的分布式事务协议，本质上和两阶段提交⼀样，需要数据库⽀持，Mysql5.6以上版本⽀持XA协议，其他数据库如Oracle，DB2也实现了XA接⼝。
AT不依赖与数据库本⾝对协议的⽀持，当然也不需要数据库⽀持 XA 协议。这点对于微服务化的架构来说是⾮常重要的：应⽤层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。
原理
Transaction Coordinator (TC)：事务协调器，维护全局事务的运⾏状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager (TM)：控制全局事务的边界，负责开启⼀个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)：控制分⽀事务，负责分⽀注册、状态汇报，并接收事务协调器的指令，驱动分⽀（本地）事务的提交和回滚。
使⽤
1. 创建Seata TC Server服务
Seata TC Server的 db 数据库为：
（1）global_table ：the table to store GlobalSession data
（2）branch_table：the table to store BranchSession data
（3）lock_table：the table to store lock data
2. 使⽤⽅数据库增加undo_log表：⽤于分⽀事务的回滚
3. ⽅法上增加@GlobalTransactional注解
执⾏过程图
特别注意的是：
1. 回滚时通过 XID 和 Branch ID 查到相应的 UNDO LOG 记录并校验。
数据校验：拿 UNDO LOG 中的后镜与当前数据进⾏⽐较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的⽂档中介绍。
2. 业务更新 ssql与插⼊到UNDO_LOG 表镜像数据是同⼀个数据。
3. 整个过程全局锁在 tx1 结束前⼀直是被 tx1 持有的，所以不会发⽣脏写的问题。
问题：
最⼤的问题：事务隔离级别最⾼⽀持到读已提交的⽔平，SQL 的解析还不能涵盖全部的语法等。
问题⼀：隔离性减弱：隔离级别变为读未提交
在数据库本地隔离级别读已提交或以上的前提下，Fescar 设计了由事务协调器维护的全局写排他锁，来保证事务间的写隔离，将全局事务默认定义在读未提交的隔离级别上。
我们对隔离级别的共识是：微服务场景产⽣的分布式事务，绝⼤部分应⽤在读已提交的隔离级别下⼯作是没有问题的。⽽实际上，这当中⼜有绝⼤多数的应⽤场景，实际上⼯作在读未提交的隔离级别下同样没有问题。
问题⼆：回滚时数据已被改变
回滚时通过 XID 和 Branch ID 查到相应的 UNDO LOG 记录并校验。
数据校验：拿 UNDO LOG 中的后镜与当前数据进⾏⽐较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理。
解决⽅式：脏数据需⼿动处理，根据⽇志提⽰修正数据或者将对应undo删除（可⾃定义实现FailureHandler做邮件通知或其他）
注：建议事前做好隔离保证⽆脏数据（加分布式锁）
官⽹：
引⽤

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。