📚 课程目录第2章分布式事务基础

集成测试下分布式事务压测场景测试与案例实战安全权限设计 - 第2节

2.1 事务与分布式事务的基本概念

在深入分布式事务的复杂理论之前，必须先厘清“事务”的本质。事务是数据库系统执行过程中的一个逻辑单元，它要么全部成功，要么全部失败。当这个逻辑单元跨越多个独立的数据库、服务或消息队列时，就演变为分布式事务。

  核心区别： 单机事务依赖本地锁与日志；分布式事务则需要在不可靠的网络环境下，协调多个独立节点达成最终一致。

ACID 是衡量事务可靠性的四个基本属性，也是分布式事务设计试图在全局范围内复现的理想模型。

属性	全称	核心含义	分布式挑战
A	原子性 (Atomicity)	事务中的所有操作，要么全部完成，要么全部不完成。	网络分区时，如何保证所有节点同时提交或回滚？
C	一致性 (Consistency)	事务执行前后，数据必须满足所有预定义的约束。	多节点间数据状态在中间时刻可能违反约束。
I	隔离性 (Isolation)	并发执行的事务之间互不干扰。	全局锁或分布式锁带来的性能急剧下降。
D	持久性 (Durability)	一旦事务提交，其结果就是永久性的。	节点宕机后，如何通过日志或副本恢复已提交的事务？

压测视角： 在集成测试中，ACID 的“隔离性”是性能瓶颈的主要来源。严格的隔离级别（如可串行化）在分布式环境下几乎无法承受高并发压测。

CAP 理论是分布式系统的基石，它指出一个分布式系统最多只能同时满足一致性、可用性和分区容错性中的两项。理解 CAP 是理解分布式事务取舍的前提。

压测陷阱： 很多压测场景默认系统是 CA 的，但一旦发生网络抖动（分区），系统行为会剧烈变化。压测必须覆盖网络分区下的 CP 或 AP 表现。

BASE 理论是 eBay 等互联网公司基于 CAP 实践总结出的思想，它放弃了强一致性，追求最终一致性，是大多数高可用分布式系统的设计哲学。

BA (Basically Available) 基本可用： 系统允许出现部分功能降级，但核心功能依然可用。例如，秒杀期间允许用户看到“稍后重试”的提示。
S (Soft State) 软状态： 允许系统存在中间状态，且中间状态不影响系统整体可用性。例如，订单状态为“支付中”。
E (Eventually Consistent) 最终一致： 经过一段时间后，所有副本的数据最终会达到一致状态。例如，转账后，两个账户的余额最终会正确。

2PC 是实现分布式事务原子性的经典算法，它将事务提交过程分为“准备”和“提交”两个阶段，由一个协调者统一管理所有参与者。

  2PC 的致命缺陷：
  同步阻塞： 参与者准备阶段会锁定资源，直到收到协调者的最终指令。
单点故障： 协调者宕机，参与者会一直阻塞，无法释放锁。
脑裂风险： 协调者发送提交指令后宕机，部分参与者收到并提交，部分未收到，导致数据不一致。

3PC 是 2PC 的改进版本，它将“准备阶段”拆分为“CanCommit”和“PreCommit”两个阶段，并引入了超时机制，以降低阻塞范围。

阶段	动作	协调者状态	参与者状态
1. CanCommit	询问所有参与者是否具备提交条件（仅检查状态，不锁定资源）	等待	返回 Yes/No
2. PreCommit	通知参与者预提交（锁定资源，写 Undo/Redo 日志）	等待 ACK	预提交完成，返回 ACK
3. DoCommit	发送最终提交指令	完成	正式提交并释放资源

3PC 的改进与不足： 3PC 通过引入超时机制，解决了协调者单点故障时的无限阻塞问题（参与者超时后会自动中止）。但 3PC 仍然无法完全解决网络分区下的数据一致性问题，且多一轮交互增加了延迟。在压测场景中，3PC 的吞吐量通常低于 2PC，但稳定性更好。

在集成测试压测场景库设计中，选择哪种理论指导下的分布式事务方案，直接决定了压测的通过标准和性能基线。

理论/协议	一致性强度	可用性	性能开销	典型压测场景
ACID (单机)	强	低	低	单库转账、本地事务基准测试
CAP (CP)	强	低	高	跨库强一致写入、金融核心链路
CAP (AP)	弱	高	中	用户信息读取、商品详情页
BASE	最终	高	中	订单状态同步、积分发放
2PC	强	低	高	跨库扣库存、账户余额变更
3PC	较强	中	高	对一致性要求极高且允许稍高延迟的场景

安全权限设计启示： 在压测场景库中，必须为不同一致性级别的分布式事务配置不同的安全权限模型。例如，强一致性场景（2PC）下的数据回滚操作，需要更高的权限审计级别；而最终一致性场景（BASE）下的补偿事务，则需要严格的幂等性校验和防重放攻击机制。