First, the transaction and distributed transactions
Affairs, in the middle of the database is the smallest unit of operation of the database, to big to see, the transaction is a series of strict application of the operation, all operations must be completed successfully, otherwise made in each operation, all changes are undone.
So why is there a distributed transaction it? Within a single transaction is in session ACID be achieved by locking the database itself and logs by operating limits. Because of the introduction of distributed architecture, so the participants of the transaction, the transaction server support, resources server and transaction manager are located on different nodes of a distributed system is different. It simply is not guarantee between multiple databases to ensure that each respective operating succeed or fail.
Second, the introduction
Seata: Simple Extensible Autonomous Transaction Architecture, simple and scalable autonomous distributed transaction management framework, its predecessor was fescar. Alibaba GTS version of the open source implementation is a solution for distributed transactions.
Third, architecture
- Coordinator Core: lowest transaction coordinator module core code is mainly used for transaction coordination logic, such as whether Commit, Rollback coordination of activities and the like.
- Store: a storage module for our data persistence, restart or downtime prevent data loss.
- Discover: service registration / discovery module for exposing Server address to the Client.
- Config: used to store and locate the configuration of the server.
- Lock: Lock module is used to provide Seata global lock function.
- Rpc: and for the other end of the communication.
- HA-Cluster: high availability cluster, is currently not open source. To provide reliable high-availability features for Seata.
Fourth, workflow
1) participate in role
Transaction Coordinator(TC)：管理全局的分支事务的状态，用于全局性事务的提交和回滚。
Transaction Manager(TM)：事务管理器，用于开启全局事务、提交或者回滚全局事务，是全局事务的开启者。
Resource Manager(RM)：资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。
2)流程
- TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
- XID在rpc中传播给每一个调用链中的服务。
- 每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
- RM完成本地分支的业务，提交本地分支，并且报告给TC。
- 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。
- 假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
- TM检测到了某个分支事务失败，向TC发起全局事务回滚。
- TC给每一个RM发送消息，通知它们全部回滚。
- TC将全局事务回滚的结果发送给TM，全局事务结束。
五、设计思想(重点)
Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，但XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，所以性能较差。
Seata 在数据源做了一层代理层，所以我们使用 Seata 时，我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，主要是解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，并将 undo log 日志插入 undo_log 表中，保证每条更新数据的业务 sql 都有对应的回滚日志存在。这样做的好处就是，本地事务执行完可以立即释放本地事务锁定的资源，然后向 TC 上报分支状态。当 TM 决议全局提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成；当 TM 决议全局回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后执行回滚日志完成回滚操作。
六、其他模式
上面说的是seata的模式模式AT,seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚。
七、总结
1)优点
- 阿里背书,社区活跃,github1.3w start。
- 相对2pc来说性能有较大提升,避免多个库锁定导致的性能急剧下降。
- 使用简单,学习成本低,对业务无入侵,对于AT模式来说,只需一个注解就可以实现分布式事务。
- 可通过HA-Cluster保证高可用。
- 灵活,拓展性高,配置,服务发现和注册,全局锁,可由用户自己实现。
2)缺点
- TC不支持集群部署,一旦TC宕机会导致无法处理分布式事务。
- Seata的引入全局锁会额外增加死锁的风险。
- 单机多数据源跨服务目前不支持。