数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。
• 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。
• 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。
• 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
• 持久性（Durability）指已提交的事务修改数据会被持久保存。
在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎所有的成熟的关系 型数据库都提供了对本地事务的原生支持。但是在基于微服务的分布式应用环境下，越来越多的应用场 景要求对多个服务的访问及其相对应的多个数据库资源能纳入到同一个事务当中，分布式事务应运而生。
关系型数据库虽然对本地事务提供了完美的 ACID 原生支持。但在分布式的场景下，它却成为系统性能 的桎梏。如何让数据库在分布式场景下满足 ACID 的特性或找寻相应的替代方案，是分布式事务的重点 工作。
本地事务
在不开启任何分布式事务管理器的前提下，让每个数据节点各自管理自己的事务。它们之间没有协调以 及通信的能力，也并不互相知晓其他数据节点事务的成功与否。本地事务在性能方面无任何损耗，但在 强一致性以及最终一致性方面则力不从心。
两阶段提交
XA 协议最早的分布式事务模型是由 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing (DTP) 模型，简称 XA 协议。
基于 XA 协议实现的分布式事务对业务侵入很小。它最大的优势就是对使用方透明，用户可以像使用本地 事务一样使用基于 XA 协议的分布式事务。XA 协议能够严格保障事务 ACID 特性。
严格保障事务 ACID 特性是一把双刃剑。事务执行在过程中需要将所需资源全部锁定，它更加适用于执 行时间确定的短事务。对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业 务系统并发性能衰退明显。因此，在高并发的性能至上场景中，基于 XA 协议的分布式事务并不是最佳选 择。
柔性事务
如果将实现了 ACID 的事务要素的事务称为刚性事务的话，那么基于 BASE 事务要素的事务则称为柔性 事务。BASE 是基本可用、柔性状态和最终一致性这三个要素的缩写。
• 基本可用（Basically Available）保证分布式事务参与方不一定同时在线。
• 柔性状态（Soft state）则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。
• 而最终一致性（Eventually consistent）通常是通过消息传递的方式保证系统的最终一致性。 在 ACID 事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。柔性事务的理念则是 通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量 的提升。
基于 ACID 的强一致性事务和基于 BASE 的最终一致性事务都不是银弹，只有在最适合的场景中才能发 挥它们的最大长处。可通过下表详细对比它们之间的区别，以帮助开发者进行技术选型。
增加xa事务相关pom配置
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-transaction-xa-core</artifactId>
<version>4.1.1</version>
</dependency>
开启xa事务
@Service
public class OrderService extends ServiceImpl<OrderMapper, Order> implements IService<Order> {
@Autowired(required = false)
private OrderMapper orderMapper;
@Transactional
@ShardingTransactionType(value = TransactionType.XA)
public void insertBoth(Order order1, Order order2) {
orderMapper.insert(order1);
orderMapper.insert(order2);
}
}
单元测试，其中第二条数据故意使用重复主键，会导致插入失败
@SpringBootTest
public class ShardingTransactionTests {
@Autowired(required = false)
private OrderService orderService;
@Test
public void testTransaction() {
Order order = new Order();
order.setUserId(0L);
order.setOrderName("test");
order.setInsertDate(new Date());
order.setId(1000L);
//第二条数据故意使用重复主键，会导致插入失败
Order order2 = new Order();
order2.setUserId(1L);
order2.setOrderName("test");
order2.setInsertDate(new Date());
order2.setId(1423300097206190082L);
orderService.insertBoth(order, order2);
}
}
运行结果
Error updating database. Cause: java.sql.SQLIntegrityConstraintViolationException: Duplicate entry '1423300097206190082' for key 't_order0.PRIMARY'
同时生成xa_tx0.log文件
{"id":"127.0.0.1.tm162818601616000001","wasCommitted":false,"participants":[{"uri":"127.0.0.1.tm1","state":"TERMINATED","expires":1628186316962,"resourceName":"resource-1-test0"},{"uri":"127.0.0.1.tm2","state":"TERMINATED","expires":1628186316962,"resourceName":"resource-2-test1"}]}
查看数据库两条数据都未插入
seata事务
1.pom文件
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-transaction-base-seata-at</artifactId>
<version>4.1.1</version>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-rm-datasource</artifactId>
<version>1.4.2</version>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-tm</artifactId>
<version>1.4.2</version>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-codec-all</artifactId>
<version>1.0.0</version>
</dependency>
2.seata配置文件 seata.conf
client {
application.id = raw-jdbc
transaction.service.group = raw-jdbc-group
}
3.配置事务
@Transactional
@ShardingTransactionType(value = TransactionType.BASE)
public void insertBothBase(Order order1, Order order2) {
orderMapper.insert(order1);
orderMapper.insert(order2);
}
