📚 课程目录第2章分布式事务概述

2、分布式事务概述：分布式事务的定义、CAP定理与BASE理论、分布式事务的挑战

在单体架构中，事务通常依赖数据库的本地 ACID 特性（原子性、一致性、隔离性、持久性）来保证一组操作要么全部成功，要么全部失败。然而，在微服务与分布式系统架构下，一个业务操作往往跨越多个独立的服务、数据库实例甚至异构存储系统。此时，传统的本地事务机制无法跨进程、跨网络保证数据的一致性。

分布式事务（Distributed Transaction）是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上，通过全局协调机制，确保跨多个独立数据源的操作满足原子性和一致性。

  核心特征： 分布式事务 = 全局事务管理器 + 多个本地资源管理器 + 两阶段/三阶段提交协议或补偿机制。

CAP 定理（又称 Brewer 定理）是分布式系统设计的基石。它指出，一个分布式系统最多只能同时满足以下三个特性中的两个：

特性	全称	说明
C	一致性（Consistency）	所有节点在同一时刻看到的数据完全相同。写操作完成后，任何后续读操作都能读到最新的写入值。
A	可用性（Availability）	系统在正常响应时间内，每个请求都能获得一个非错误的响应（不保证数据是最新的）。
P	分区容错性（Partition Tolerance）	系统在遇到网络分区（节点间通信中断）时，仍能继续正常运行。

由于网络分区在分布式系统中是不可避免的，因此实际设计时必须在 CP（放弃可用性，保证强一致）和 AP（放弃强一致，保证可用性）之间做出权衡。绝大多数互联网业务场景选择 AP，通过最终一致性来弥补。

实践启示： 在事件风暴画布中识别聚合边界时，如果某个业务操作跨多个聚合且对实时一致性要求极高，应优先考虑将相关聚合合并到同一个限界上下文内，以减少分布式事务的引入。

BASE 理论是对 CAP 定理中 AP 方案的延伸，它强调通过牺牲强一致性来换取可用性和系统伸缩性，最终达到数据的最终一致性。BASE 是以下三个概念的缩写：

  BASE 与 ACID 的对比： ACID 追求强一致，适用于对数据准确性要求极高的金融、账务场景；BASE 追求最终一致，适用于高并发、高可用的互联网场景（如社交、电商、内容平台）。

在事件风暴画布中识别出跨聚合、跨限界上下文的业务事件后，分布式事务的实现将面临以下核心挑战：

挑战维度	具体问题	对架构的影响
网络不可靠	节点间通信可能超时、丢包、乱序，导致事务协调器无法准确判断参与者状态。	需要引入超时重试、幂等性设计、事务日志持久化。
节点故障	参与事务的某个服务或数据库宕机，导致事务长时间挂起或阻塞。	必须设计故障恢复机制（如 Saga 补偿、TCC 空回滚）。
数据一致性窗口	在最终一致性模型中，从数据写入到所有节点达成一致存在时间差。	业务层需要容忍短暂的不一致，或通过读修复、版本向量等手段缓解。
性能开销	分布式事务协调（如两阶段提交）需要多次网络往返和锁资源，吞吐量远低于本地事务。	高并发场景下应优先考虑异步消息 + 本地事件表，避免同步阻塞。
隔离性缺失	跨服务的事务无法像本地数据库那样提供严格的隔离级别，脏读、不可重复读更易发生。	需在应用层实现乐观锁、版本号或业务级防重放控制。

事件风暴中的关键提醒： 在绘制“聚合”和“事件”时，如果发现某个业务流程需要跨 3 个以上的聚合且要求强一致，这通常是架构设计上的“坏味道”。建议重新审视聚合边界划分是否合理，或考虑引入事件溯源（Event Sourcing） + CQRS 模式来规避分布式事务。

根据协调方式与一致性强度，分布式事务可分为以下主流类别，后续章节将逐一深入：

强一致类： 两阶段提交（2PC）、三阶段提交（3PC）。适用于对一致性要求极高、并发量较低的内部系统。
最终一致类： TCC（Try-Confirm-Cancel）、Saga（编排/协同）、本地消息表、事务消息（RocketMQ）。适用于高可用、高吞吐的互联网业务。
混合类： 最大努力通知、可靠消息最终一致。适用于对实时性要求不高的异步场景。

课程路线预告： 第 3 章将详细拆解 2PC 与 3PC 的协议细节与性能瓶颈；第 4 章开始进入 TCC 与 Saga 在事件风暴画布中的建模实践。