分布式事务框架有哪些

什么是事务？

事务从本质上讲就是：逻辑上的一组操作，组成这组操作的各个逻辑单元在不同的服务甚至服务器上，保证它们要成功就都成功，要失败就都失败。

事务的四大特性
提到事务就不得不提事务的四大特性(基本特征) ACID：

原子性(atomicity)：“原子”的本意是“不可再分”，事务的原子性表现为一个事务中涉及到的多个操作在逻辑上缺一不可。事务的原子性要求事务中的所有操作要么都执行，要么都不执行。

一致性(consistency)：“一致”指的是数据的一致，具体是指：所有数据都处于满足业务规则的一致性状态。一致性原则要求：一个事务中不管涉及到多少个操作，都必须保证事务执行之前数据是正确的，事务执行之后数据仍然是正确的。如果一个事务在执行的过程中，其中某一个或某几个操作失败了，则必须将其他所有操作撤销，将数据恢复到事务执行之前的状态，这就是回滚。

隔离性(isolation)：在应用程序实际运行过程中，事务往往是并发执行的，所以很有可能有许多事务同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。隔离性原则要求多个事务在并发执行过程中不会互相干扰。

持久性(durability)：持久性原则要求事务执行完成后，对数据的修改永久的保存下来，不会因各种系统错误或其他意外情况而受到影响。通常情况下，事务对数据的修改应该被写入到持久化存储器中。

分布式事务

为什么要有分布式事务?
本地事务只能解决同一工程中的事务问题，而现在的场景更加复杂，关系到多个服务，怎么保证要么都成功，要么都失败？
分布式系统异常除了本地事务那些异常之外，还有：机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失等，这时候就需要引入分布式事务。

分布式事务出现的场景
不同的服务，不同数据库

相同的服务，不同数据库

不同的服务，相同数据库

主流的分布式事务框架分类及代表方案，覆盖不同技术栈与一致性模型：

‌一、Java 技术栈框架‌

‌1. AT/XA 模式主导‌

‌2. 消息事务方案‌

‌3. Saga 长事务方案‌

‌二、.NET 技术栈框架‌

‌三、多语言通用框架‌

‌四、选型关键维度‌

‌附：一致性模型对照‌

• ‌CP模型‌（强一致）：XA、TCC
• ‌AP模型‌（最终一致）：Saga、事务消息

‌五、典型架构示例‌

‌Seata AT模式流程‌

[TM]@GlobalTransactional
    │
    ├─1. 调用服务A（RM） → 生成SQL快照（Undo Log）
    │   └─ 注册分支事务到TC
    │
    └─2. 调用服务B（RM） → 生成SQL快照
        └─ TC全局提交/回滚决策 → 异步清理或补偿

‌RocketMQ事务消息流程‌

[Producer]
    │  1. 发送半消息（对Consumer不可见）
    │
    ├─2. 执行本地事务（如订单创建）
    │
    └─3. 本地事务成功 → 提交消息（Consumer可见）
        失败 → 回滚消息（MQ自动删除）

‌避坑指南‌：

• Seata AT模式需数据库支持‌行锁‌（如MySQL InnoDB）
• TCC模式需业务层实现‌幂等‌与‌空回滚‌防御