问题

什么是分布式事务？

答案

1. 核心概念

分布式事务是指事务的参与者、支持事务的服务器、资源管理器以及事务管理器分别位于不同的分布式系统的不同节点上的事务。简单来说，就是一次操作涉及多个数据源或多个服务，需要保证这些操作要么全部成功，要么全部失败。

典型场景示例：

  • 电商下单：扣减库存（库存服务）+ 创建订单（订单服务）+ 扣减余额（账户服务）
  • 转账业务：账户A扣款（数据库A）+ 账户B加款（数据库B）
  • 跨库分表：同一业务数据分布在多个数据库实例

2. 分布式事务的产生背景

单体应用 vs 分布式系统

单体应用的事务：

@Transactional
public void createOrder(Order order) {
    // 所有操作在同一个数据库
    orderDao.insert(order);           // 插入订单
    inventoryDao.decrease(order);      // 扣减库存
    accountDao.deduct(order);          // 扣减账户
    // 统一由本地事务管理
}

在单体应用中，所有操作都在同一个数据库事务中，由数据库的ACID特性保证一致性。

分布式系统的事务：

public void createOrderDistributed(Order order) {
    // 不同操作在不同的服务/数据库
    orderService.createOrder(order);          // 订单服务
    inventoryService.decreaseStock(order);    // 库存服务
    accountService.deductBalance(order);      // 账户服务
    // 每个服务独立的数据库，本地事务无法覆盖
}

在微服务架构下，每个服务拥有独立的数据库，传统的本地事务无法跨服务保证一致性。

3. 分布式事务面临的挑战

挑战1：CAP理论的约束

CAP理论：

  • C (Consistency)：一致性，所有节点同一时间看到相同数据
  • A (Availability)：可用性，每个请求都能得到响应
  • P (Partition Tolerance)：分区容错性，系统在网络分区时仍能工作

核心矛盾：CAP三者不可兼得，分布式系统必须容忍分区（P），只能在C和A之间权衡。

挑战2：网络不可靠 

服务A          网络          服务B
  |   ----请求---->   X      | (网络超时/丢包)
  |              (未收到响应)  | (可能已执行/未执行)
  |   <---响应----   X       |

问题：

  • 网络延迟：无法确定操作是否执行
  • 网络分区：部分服务不可达
  • 超时不确定性：超时不代表失败，可能已执行

挑战3：部分失败 

阶段      操作                  结果
1    创建订单(订单服务)         ✓ 成功
2    扣减库存(库存服务)         ✓ 成功
3    扣减余额(账户服务)         ✗ 失败

前面的操作已提交，后面的操作失败，如何回滚？

4. 分布式事务的核心问题

问题1：原子性（Atomicity）

多个服务的操作如何保证”全部成功”或”全部失败”？

问题2：一致性（Consistency）

跨服务的数据如何保持一致？是强一致还是最终一致？

问题3：隔离性（Isolation）

并发的分布式事务之间如何隔离？

问题4：持久性（Durability）

操作成功后如何保证数据不丢失？

5. 理论基础：从ACID到BASE

ACID（强一致性）

  • Atomicity（原子性）：全部成功或全部失败
  • Consistency（一致性）：事务前后数据一致
  • Isolation（隔离性）：并发事务互不干扰
  • Durability（持久性）：提交后永久生效

问题：在分布式环境下，严格的ACID代价过高（性能、可用性）。

BASE（最终一致性）

  • Basically Available（基本可用）：允许损失部分可用性
  • Soft State（软状态）：允许中间状态存在
  • Eventually Consistent（最终一致性）：最终达到一致

理念：牺牲强一致性，换取更高的可用性和性能。

6. 分布式事务的分类

刚性事务

追求强一致性，遵循ACID原则。

  • 代表方案：2PC、3PC、XA协议
  • 特点：一致性强、性能较低、适用于金融等对一致性要求极高的场景

柔性事务

追求最终一致性，遵循BASE理论。

  • 代表方案：TCC、Saga、本地消息表、事务消息
  • 特点：性能高、可用性好、适用于互联网大多数场景

7. 分布式事务与本地事务对比

维度 本地事务 分布式事务
数据源 单一数据库 多个数据库/服务
事务管理 数据库管理器 分布式事务协调器
一致性 强一致性（ACID） 强一致或最终一致
性能 高 相对较低
复杂度 低 高
可用性 受单点影响 需考虑网络分区
实现方式 @Transactional注解 2PC/TCC/Saga等

8. 总结

核心要点：

  1. 定义：分布式事务是跨多个服务/数据源的事务，需要保证整体的一致性
  2. 产生原因：微服务架构、分库分表导致单一事务无法覆盖所有操作
  3. 核心挑战：CAP约束、网络不可靠、部分失败
  4. 理论权衡：从ACID到BASE，从强一致性到最终一致性
  5. 解决思路：刚性事务（强一致）和柔性事务（最终一致）

面试要点：

  • 能够清晰描述分布式事务的定义和产生背景
  • 理解CAP理论对分布式事务的约束
  • 掌握ACID和BASE的区别和适用场景
  • 理解刚性事务和柔性事务的差异

实际应用：

  • 并非所有场景都需要分布式事务
  • 优先考虑业务层面的优化（如异步、幂等）
  • 根据业务特性选择合适的一致性级别
  • 在性能、一致性、复杂度之间做好权衡