【分布式系统】之 分布式事务解决方案 Seata

一、什么是分布式事务？

分布式事务，分开来讲就是分布式和事务。

什么是分布式？

分布式：是一种抽象规范，即分别部署在不同的服务器节点的模式

分布式包括：

1. 不同功能的模块的分开部署
2. 相同功能的模块基于高性能高并发高可用的集群部署

什么是事务？

事务：是一组原子性的执行过程，该过程要么全部执行成功，要么全部执行失败，不存在中间状态。

二、分布式事务面临的问题？

在分布式部署的场景下，出现的问题主要有：

1. 数据一致性
2. 数据可用性
3. 分区容错性

CAP原理：

1. C 一致性
2. A 可用性
3. P 分区容错性

在分布式环境下，总是会存在部分服务节点故障或数据同步时网络抖动等问题，这就将数据分成了新的和旧的两个部分，所以P是永远存在的。而若要保证C，则在发生数据分区后，必须加锁，保证数据先同步完成，然后再被使用，这样在这个时候，可用性A很明显是不能保证的。若是要保证A，则P分区的数据都可能被访问到，这时很明显是不符合一致性的原则，故一致性C是不能保证的。所有在分布式环境下，只能存在CP或者AP

BASE理论：

1. BA 基本可用
2. S 软状态
3. E 最终一致性

三、Seata是什么？

1、简述：

描述：一款开源的分布式事务解决方案
愿景：致力于提供高性能和简单易用的分布式事务服务
提供：提供了AT、TCC、SAGA和XA四种事务模式

2、Seata角色：

1. TC (Transaction Coordinator) - 事务协调者

   维护全局和分支事务的状态，驱动全局事务提交或回滚。

2. TM (Transaction Manager) - 事务管理器：定义全局事务的范围

   开始全局事务、提交或回滚全局事务。

3. RM (Resource Manager) - 资源管理器：

   管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

以购买商品的业务逻辑为例：

用户购买商品的业务逻辑。整个业务逻辑由 3 个微服务提供支持：

1. 仓储服务：对给定的商品扣除仓储数量。
2. 订单服务：根据采购需求创建订单。
3. 帐户服务：从用户帐户中扣除余额。

架构图

SEATA 的分布式交易解决方案：

3、Seata模式：

	AT	TCC	SAGA	XA
优势	1.一阶段完成直接提交事务，释放数据库资源，性能比较好。2.利用全局锁实现读写分离。3.没有代码侵入，框架自动完成回滚和提交	完全不依赖底层数据库，能够实现跨数据库、跨应用资源管理，可以提供给业务方更细粒度的控制	1.一阶段提交本地事务，无锁，高性能。2.事件驱动架构，参与者可异步执行，高吞吐 3.补偿服务易于实现	1.事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。2.业务无侵入：和 AT 一样，XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担。3.数据库的支持广泛：XA 协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。
缺点	1.两阶段之间属于软状态，属于最终一致。2.框架的快照功能会影响性能，但比XA模式要好得多	是一种侵入式的分布式事务解决方案，需要业务系统自行实现 Try，Confirm，Cancel 三个操作，对业务系统有着非常大的入侵性，设计相对复杂。	不保证隔离性	XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，性能差。
使用场景		TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。	1.业务流程长、业务流程多。2.参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口	适用于想要迁移到 Seata 平台基于 XA 协议的老应用，使用 XA 模式将更平滑，还有 AT 模式未适配的数据库应用。
数据源支持	支持MySQL、Oracle、PostgreSQL、TiDB、MariaDB	1.4.2 版本及之前：不依赖数据源。1.4.2版本之后，添加了TCC防悬挂措施，需要数据源支持	不依赖数据源	只支持实现了XA协议的数据库。包括MySQL、Oracle、PostgreSQL和MariaDB

4、Seata支持的配置中心和注册中心

1. Nacos
2. Apollo
3. Etcd3
4. Consul
5. Zookeeper