📘 事务体系总结：本地事务、本地事务与分布式事务详解
🧩 1. 什么是事务（Transaction）？
事务是一组数据库操作的逻辑单元，这些操作要么全部成功、要么全部失败，保证数据的完整性与一致性。
事务具备数据库的 ACID 特性：
- A（原子性）：全部执行或全部不执行
- C（一致性）：事务前后数据总量一致
- I（隔离性）：不同事务之间互不干扰
- D（持久性）：提交后的数据永久保存
🟩 2. 本地事务（Local Transaction）
✔ 定义
本地事务指 单个服务操作单个数据库 时，由数据库自己保证 ACID 特性的事务。
⭐ 本地事务 =
@Transactional的控制范围它保证当前服务的所有 SQL 要么全部成功，要么全部回滚。
✔ 使用示例（Spring Boot）
@Transactional
public void createOrder() {
insertOrder();
insertOrderItem();
updateStock();
}✔ 特点
- 高性能
- 简单易用
- 数据库原生支持
- Spring Boot 直接支持
@Transactional
✔ 限制
- 无法跨服务保证一致性
- 无法跨多个数据库进行事务管理
🟦 3. 为什么需要分布式事务？
在微服务架构中，一个业务流程往往涉及多个服务：
订单服务 → 操作订单库
库存服务 → 操作库存库
支付服务 → 操作支付库如果你在订单服务写：
@Transactional
public void placeOrder() {
saveOrder();
callStockService(); // 扣库存
}即使这个方法回滚，库存服务已经扣了库存，不会自动回滚，因为：
⚠ 本地事务无法影响其他服务的数据库。
因此在微服务中需要更高级别的------分布式事务。
🟥 4. 分布式事务（Distributed Transaction）
分布式事务是指保证跨多个服务、多个数据库之间的数据一致性。
常见的分布式事务方案：
4.1 XA（两阶段提交，2PC）
流程：
- Prepare：各数据库锁住资源
- Commit：全部通过后正式提交
优点：
- 强一致性
缺点：
- 性能差
- 数据库锁时间长
- 互联网项目极少使用
4.2 TCC（Try / Confirm / Cancel）
三步执行：
- Try：检查资源、预留资源（如冻结资金）
- Confirm：正式提交
- Cancel：出错后回滚
优点：
- 更灵活
- 可实现强一致性
缺点：
- 开发成本高，需要写三套业务逻辑
代表实现：Seata TCC
4.3 AT 模式（Seata 最常用）
- 自动记录 Undo Log
- 自动回滚
- 对开发无侵入
适合大多数互联网业务。
4.4 Saga（长事务）
- 每个步骤是一个本地事务
- 出错靠补偿事务逆向回滚
更加适合长链路、跨系统调用。
🟨 5. 最终一致性事务（高并发场景最常用）
最终一致性事务允许数据短时间不一致，通过异步消息最终达成一致。
常见实现：
- RocketMQ 事务消息
- Kafka 事务消息
- 本地消息表 + MQ
适合高并发业务：
如：
- 下单成功 → 发送消息 → 库存服务扣减库存
- 如果库存扣失败，服务会自动进行补偿或重试
⭐ CAP 原理下的最佳折中方案（牺牲强一致性，获得可用性和高性能）
🟨 6. 三类事务对比
| 事务类型 | 应用场景 | 一致性 | 性能 | 开发难度 |
|---|---|---|---|---|
| 本地事务 | 单服务单数据库 | 强一致性 | ⭐⭐⭐⭐⭐ | ⭐ |
| 分布式事务 | 多服务多数据库 | 强一致性（视方案而定） | ⭐~⭐⭐ | ⭐⭐⭐⭐⭐ |
| 最终一致性 | 高并发异步业务 | 最终一致 | ⭐⭐⭐⭐⭐ | ⭐⭐ |
🟦 7. @Transactional 的核心总结
| 场景 | @Transactional 是否有效 |
说明 |
|---|---|---|
| 单体项目 | ✔ 完全可用 | 本地事务 |
| 单服务 → 单数据库 | ✔ 可用 | 微服务也可以 |
| 多服务 → 多数据库 | ❌ 无效 | 不能跨服务事务 |
| 分布式事务 | ❌ 自己不够 | 需要 Seata / TCC / XA 等 |
🟢 8. 总结一句话
本地事务保证"当前服务 + 当前数据库"的一致性，分布式事务保证跨服务一致性，最终一致性则保证大规模系统的异步一致性。
@Transactional= 本地事务，不等于分布式事务。