📚 课程目录第2章基础概念

基础概念：事务（Transaction）的定义、ACID特性、分布式事务与本地事务的区别

1. 事务（Transaction）的定义

事务是数据库管理系统（DBMS）或分布式系统中执行的一个逻辑工作单元，它由一系列不可分割的操作步骤组成。事务的核心理念是：要么全部成功，要么全部失败回滚，不存在中间状态。

在 ControlTransaction 队列管理体系中，事务被抽象为一个具有明确边界的状态机，通常包含以下生命周期：

  事务生命周期状态：

  Active（活动） → Partially Committed（部分提交） → Committed（已提交）

  Active（活动） → Failed（失败） → Aborted（中止）

2. ACID 特性详解

事务必须满足四个核心特性，即 ACID。这四个特性是保证数据一致性和可靠性的基石，也是 ControlTransaction 队列并发控制策略的设计依据。

特性	全称	含义与在队列管理中的体现
A	Atomicity（原子性）	事务中的所有操作要么全部执行成功，要么全部不执行。在队列中，若某个操作失败，整个事务回滚，队列状态恢复到事务开始前。
C	Consistency（一致性）	事务执行前后，数据必须满足所有预定义的约束规则。队列中的消息顺序和状态转换不能破坏业务逻辑的一致性。
I	Isolation（隔离性）	并发执行的事务之间互不干扰。队列系统通过锁机制或乐观并发控制（OCC）保证每个事务看到一致的数据快照。
D	Durability（持久性）	一旦事务提交，其结果永久保存。在队列中，已提交的消息必须写入持久化存储，即使系统崩溃也不会丢失。

实践提示：在 ControlTransaction 队列中，原子性和持久性通常通过预写日志（WAL）实现；隔离性通过队列的 FIFO 顺序和事务级快照隔离（SI）来保障。

3. 本地事务（Local Transaction）

本地事务是指在单个数据库或单个数据源范围内执行的事务。它由本地资源管理器（如 MySQL InnoDB 引擎）直接管理，不涉及跨节点协调。

管理范围：单一数据库连接（Connection）内。
实现方式：通过 BEGIN TRANSACTION、COMMIT、ROLLBACK 语句控制。
典型场景：单体应用、单库操作、简单的 CRUD 业务。
优势：性能高、实现简单、无网络开销。
局限：无法跨数据库或跨服务保证一致性。

-- 本地事务示例（MySQL）
BEGIN TRANSACTION;

UPDATE account SET balance = balance - 100 WHERE user_id = 1;
UPDATE account SET balance = balance + 100 WHERE user_id = 2;

COMMIT;
-- 若中间出错，执行 ROLLBACK

4. 分布式事务（Distributed Transaction）

分布式事务是指涉及多个独立数据节点（数据库、消息队列、微服务）的事务，需要全局协调器（Coordinator）来保证所有参与者要么全部提交，要么全部回滚。

管理范围：跨多个数据库、消息队列、或微服务。
实现方式：两阶段提交（2PC）、三阶段提交（3PC）、TCC（Try-Confirm-Cancel）、Saga 模式。
典型场景：微服务架构、跨库转账、订单与库存的分布式协调。
挑战：网络延迟、节点故障、协调者单点问题、性能开销大。

注意：分布式事务无法完全满足 ACID 中的隔离性（I），通常退化为 BASE（基本可用、软状态、最终一致性）理论。在 ControlTransaction 队列中，分布式事务常通过 Saga 模式或本地消息表实现最终一致性。

5. 本地事务 vs 分布式事务：核心区别

对比维度	本地事务	分布式事务
数据源范围	单个数据库或单个资源	多个数据库、消息队列、服务
协调机制	本地资源管理器（如 InnoDB）	全局事务协调器（Coordinator）
一致性模型	强一致性（ACID）	最终一致性（BASE）
性能	高（毫秒级）	低（秒级，网络开销大）
典型协议	单阶段提交	2PC、3PC、TCC、Saga
故障影响	仅影响当前连接	可能阻塞全局资源
适用架构	单体应用	微服务、分布式系统

6. 在 ControlTransaction 队列中的选择策略

在 ControlTransaction 队列管理与并发控制框架中，选择本地事务还是分布式事务取决于业务场景：

  决策原则：

  • 若所有操作在同一个数据库实例内 → 优先使用本地事务，性能最优。

  • 若操作跨数据库、跨消息队列或跨微服务 → 使用分布式事务，推荐 Saga 模式或本地消息表 + 定时补偿。

  • 在队列消费场景中，建议将分布式事务拆解为多个本地事务 + 消息驱动，避免长事务锁住队列。