分布式事务

一、第一性原理：什么是分布式事务

1.1 事务的本质

事务不是数据库特性，而是一种状态一致性约束机制。

从第一性原理看，事务要解决的并非“提交或回滚”本身，而是以下四个根本问题：

维度本质问题
原子性失败后如何恢复到可接受状态
一致性系统状态如何从一个合法状态收敛到另一个合法状态
隔离性并发下状态对其他行为的可见性
持久性状态一旦确认，如何避免丢失

单机数据库通过强一致存储 + 锁 + 日志隐式解决了这些问题。

1.2 为什么分布式事务必然困难

当系统进入分布式环境后，事务面临三个不可回避的前提：

  1. **网络不可靠**（消息可能丢失、延迟、乱序）
  2. **节点自治**（每个服务/数据库独立决策）
  3. **部分失败是常态**（而非异常）

这意味着：

事务从“数据库能力”退化为“架构能力”

分布式事务的本质目标变为：

在 CAP 不可兼得前提下，对一致性、可用性、复杂度进行工程化权衡。

二、事务能力的演进路径

2.1 从本地事务到全局事务

阶段事务能力来源特点
单体系统单机数据库ACID 完整
多数据库XA / 2PC强一致、低可用
微服务业务协调最终一致、高可用
事件驱动消息 + 状态机去中心、可演进

关键结论：

系统越分布，事务越上移到业务与架构层。

三、分布式事务的失败模型

任何分布式事务设计，都必须正视以下失败模式：

因此：

失败不是异常路径，而是主路径的一部分。

这直接决定了后续所有方案的设计哲学。

四、三类分布式事务解决路径（抽象模型）

从稳定知识角度，所有分布式事务方案可归为三类。

4.1 基础设施型：强一致事务（XA / 2PC / 3PC）

核心思想：通过中心化协调，强制所有参与者达成一致。

适合：金融核心账务、低并发强一致场景

本质牺牲： 可用性与扩展性

4.2 架构协调型：TCC / Saga

4.2.1 统一抽象：显式状态机

无论 TCC 还是 Saga，本质都是：

INIT → TRY → CONFIRM / CANCEL → DONE

即：

TCC

Saga

适合：核心交易但需高可用的系统

本质牺牲： 隔离性，换取可用性

4.3 业务容错型：消息驱动最终一致性

核心思想：

放弃“瞬时一致”，追求“可观测的最终一致”。

常见模式：

其统一抽象为：

适合：跨系统、跨组织、跨网络场景

本质牺牲： 实时一致性

五、统一能力坐标系：如何选型

方案一致性可用性隔离性协调方式复杂度
XA / 2PC强低强中心化低
3PC较强较低强中心化中
TCC最终高业务保证中心化高
Saga最终高弱编排 / 协作高
消息事务最终高无异步中

选型原则：

六、隔离性与补偿的工程对策

Saga / 消息事务天然缺乏隔离性，常见对策包括：

不是消除风险，而是控制风险。

七、治理视角：分布式事务是组织问题

分布式事务不仅是技术问题，更是协作问题：

必须配套：

八、核心结论（长期稳定认知）

  1. 分布式事务无法“完美解决”，只能权衡
  2. 强一致 ≠ 高级，最终一致 ≠ 低级
  3. 系统越分布，事务越业务化
  4. 所有分布式事务，本质都是状态机 + 补偿
  5. 架构设计的目标不是避免失败，而是**驯服失败**

关联内容（自动生成）