Seata工作流程
Seata的配置比较多，但是真正使用的时候非常简单，在业务代码事务开始的地方使用@GlobalTransactional注解就可以了。
Seata中的一些名词解释，上篇文中已经说过了，这里再提一下：
-
Transaction ID XID:全局唯一事务ID
-
TC(Transaction Coordinator):事务协调者，维护全局事务运行，驱动全局事务的提交和回滚
-
TM(Transaction Manager):事务管理器，定义全局事务边界，负责开启全局事务，发起全局事务的提交或回滚决议
-
RM(Resource Manager):资源管理器，管理分支事务，与TC(事务协调者)通信，决定对分支事务提交或回滚
那么Seata是如何实现的事务回滚呢？
用上篇的订单服务和配送服务案例大致了解一下Seata(AT事务模式)的运行流程：
-
订单服务TM向TC申请开启一个全局事务，Seata服务单TC返回全局事务的ID
(XID) -
订单服务RM向Seata服务端TC注册一个分支事务，Seata服务端TC返回分支事务ID（BranchID），将其纳入对应全局事务(XID)管辖
-
订单服务RM创建订单，向数据库插入订单数据，并且记录
undo_log日志，提交本地分支事务。向Seata服务端TC汇报分支事务处理结果 -
订单服务RM远程调用配送服务，调用时传递全局事务ID（XID）
-
配送服务RM向Seata服务端TC注册分支事务，Seata服务端TC返回分支事务ID(BranchID)将其纳入全局事务(XID)管辖
-
配送服务RM分配订单配送员，向数据库插入订单配送关系数据，并且记录
undo_log日志，提交本地分支事务，向Seata服务端TC汇报分支事务处理结果 -
订单服务TM根据有无异常发起全局事务决议提交或者回滚
-
Seata服务端TC根据订单服务TM的决议，向其管辖的所有的分支事务发起提交或者回滚。如果提交，删除undo_log日志。如果是回滚，根据undo_log表记录逆向回滚本地事务，把数据还原，最后依然是删除undo_log日志
所以说，最后两个数据库的undo_log日志表都是不存在数据，只是在Seata的工作流程中存在过数据，最后不管是提交事务还是回滚，undo_log表数据都是空的。
大致流程如图所示：
Seata服务端高可用
Seata作为服务端TC(事务协调者)的角色，地位十分重要，在大流量的场景下，保证服务端高可用是很有必要的。
前面将关于Seata的配置和注册及表放到了Nacos和mysql中了，现在要做高可用就很容易了，只需要多启动Seata服务端即可。
前文链接地址：Seata介绍及使用
如将Seata的服务端复制一份，在启动一个Seata的服务端，此时8091端口是占用的，换个端口8092或其他都行
seata-server.bat -p 8092
直接启动后，nacos上面seata-server服务会注册到两个实例，它们都可以作为服务端通过轮询或其他算法被进行使用。
调用下/createOrder的接口，发现同样可以实现事务的回滚
看下控制台日志：
最后看下数据库数据是否入库：
事务回滚，数据也没有入库，完成事务的控制。
原文始发于微信公众号（小路同学ovo）：Seata的工作流程及实现高可用
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/267774.html
