3. 分布式事务进阶：三阶段提交(3PC)、TCC模式、Saga模式、本地消息表

在分布式系统中，两阶段提交（2PC）虽然提供了强一致性保证，但其同步阻塞、单点故障和脑裂风险在高并发场景下逐渐成为瓶颈。本章深入剖析三阶段提交（3PC）、TCC模式、Saga模式与本地消息表四种进阶方案，从设计原理、适用场景到可观测性埋点策略，帮助你在连接池水位巡检与OpenTelemetry集成中精准定位事务异常。

3.1 三阶段提交（3PC）—— 引入超时与预提交

3PC是2PC的改进版本，将2PC的“提交请求-提交”两阶段拆分为“CanCommit、PreCommit、DoCommit”三个阶段，并在协调者和参与者中均引入超时机制，降低阻塞范围。

3.2 TCC模式——Try-Confirm-Cancel

TCC模式是一种补偿型事务方案，将每个服务操作拆分为Try（预留资源）、Confirm（确认执行）、Cancel（取消回滚）三个阶段。业务方需要自行实现正向和反向操作，适用于短事务、高吞吐场景。

TCC与2PC/3PC的对比

3.3 Saga模式——长事务的补偿艺术

Saga模式将一个大事务拆分为多个本地事务，每个本地事务对应一个补偿操作。Saga有两种执行方式：Choreography（编排）和Orchestration（编排器）。前者通过事件驱动，后者由中央协调器控制流程。

Saga与TCC的核心差异

3.4 本地消息表——最终一致性的经典实现

本地消息表将分布式事务拆解为“本地事务+消息队列”的组合：业务操作和消息写入在同一个本地事务中完成，消息由异步任务确保最终投递到下游服务。该方案无XA开销，适用于对实时性要求不高的场景。

本地消息表执行步骤

1. 开启本地事务： 在服务A中开启数据库事务。
2. 执行业务操作： 更新业务表（如订单状态）。
3. 插入消息记录： 在本地消息表中插入一条状态为“待投递”的消息。
4. 提交本地事务： 事务提交后，业务数据和消息同时持久化。
5. 异步投递消息： 后台定时任务或消息队列客户端读取“待投递”消息，发送到MQ。
6. 下游消费： 服务B消费消息并执行本地操作，成功后回调确认消息状态为“已投递”。
7. 失败重试： 投递失败或下游处理失败时，消息保持“待投递”状态，定时任务重试。

本地消息表结构示例

CREATE TABLE local_message (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    business_id VARCHAR(64) NOT NULL COMMENT '业务ID',
    message_body TEXT NOT NULL COMMENT '消息体（JSON）',
    status TINYINT NOT NULL DEFAULT 0 COMMENT '0:待投递 1:已投递 2:已消费',
    retry_count INT NOT NULL DEFAULT 0 COMMENT '重试次数',
    max_retry INT NOT NULL DEFAULT 5 COMMENT '最大重试次数',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_status_retry (status, retry_count)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

四种方案综合对比