分布式事务-Seata

事务简介

事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。在关系数据库中，一个事务由一组SQL语句组成，事务具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID原则。

• 原子性(atomicity): 事务中的操作要么都发生，要么都不发生
• 一致性(consistency): 事务从一个一致性的状态变到另一个一致性的状态，
• 隔离性(isolation): 事务之间不能相互干扰、相互隔离，隔离又分为四个级别: 读未提交(read uncommitted), 读已提交(read committed,解决脏读)、可重复读(rpeatable read ,解决不可重复读)、串行化(serializable 解决幻读)
• 持久性(durability): 持久性也称为永久性(permanence)，指一个事务一旦提交，它对数据库中数据的改变是永久的，接下来的操作或故障不应该对其有任何影响。

本地事务

大多数场景下，我们的应用都只需要操作单一的数据库，这种情况的事务我们称之为本地事务(Local Transation)。本地事务的ACID特性是数据库直接提供支持

Seata

seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata将为用户提供了AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案。AT模式是阿里首推的模式，阿里云上有商用版本的GTS(Global Transaction Service 全局事务服务)

TC(Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚
TM(Transaction Manager) - 事务管理器
RM(Resource) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
其中，TC为单独部署的Server服务端，TM和RM为嵌入到应用中的Client客户端。

两阶段提交
两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务

1. 准备阶段
   协调者询问参与者事务是否执行成功，参与者发回事务执行结果。
2. 提交阶段
   如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。
   需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。
   存在问题
   1.同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。
   2.单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。
   3.数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

AT(auto transcation)模式

AT模式是一种无侵入的分布式事务解决方案
阿里的seata框架，实现了该模式
在AT模式下，用户只需关注自己的“业务SQL”，用户的“业务SQL”作为第一阶段，Seata框架会自动生成事务的二阶段提交和回滚操作。

优点
一阶段完成直接提交事务，不涉及全局事务协调器，从而提高性能。
AT 模式引入全局锁和写隔离，可以防止脏写问题和提供写隔离。
没有代码侵入，框架自动完成回滚和提交，降低了开发复杂度。
缺点
数据库最终一致性在二阶段检查和修复，有可能导致数据最终一致性问题。

TCC（补偿事务）

• 侵入性强，并且得自己实现相关事务控制逻辑
• 整个过程中基本没有锁，性能更强
TCC模式需要用户根据自己的业务场景实现Try,Confirm和Cancel三个操作;事务发起方在一阶段执行try方式，在二阶段提交执行Contirm方法；二阶段回滚执行Cancel方法。

优点
一阶段直接提交，不依赖事务，依赖补偿操作，性能更好。
适用非事务型数据库。

Saga模式

SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

业务流程长、业务流程多。
参与者包含其它公司或者遗留系统服务，无法提供 TCC 模式要求的三个接口。

SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：
通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚
优点
SAGA 模式是专门用于处理分布式事务的模式，能够有效解决跨多个服务的复杂事务问题。
由于事务被分解成多个小事务，这些小事务可以并行执行，提高了系统的可伸缩性。
缺点
复杂性：SAGA 模式的实现相对复杂，需要编写和维护compensating和confirming操作，以及确保正确的状态迁移。
SAGA 模式只追求最终一致性，可能会在事务过程中出现一时的不一致，需要额外的处理来处理这些不一致。

其他方式

本地消息表（异步确保）
本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。
在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

MQ 事务消息

以阿里的 RocketMQ 中间件为例，其思路大致为：
第一阶段Prepared消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

小结

提示：这里可以添加总结

例如：

提供先进的推理，复杂的指令，更多的创造力。