Distributed-Systems on Orangex-position0的技术博客

使用 TCC 模式处理分布式事务一致性

Tue, 26 May 2026 19:10:00 +0800

背景 & 问题

在分布式系统中，一个业务操作往往涉及多个服务。比如电商下单：库存服务扣减库存、订单服务创建订单、支付服务冻结金额。这些操作要么全部成功，要么全部失败——这就是分布式事务问题。

传统的单体应用可以用数据库事务（ACID）轻松解决，但分布式环境下，每个服务有自己的数据库，无法共享一个事务。常见的分布式事务方案有：

方案	核心思路	主要问题
2PC（两阶段提交）	协调者统一控制所有参与者的提交/回滚	同步阻塞、单点故障、性能差
3PC（三阶段提交）	在 2PC 基础上增加"预提交"阶段降低阻塞	实现复杂，仍存在网络分区问题

这些方案依赖数据库层面的全局锁，在高并发场景下性能瓶颈明显。

本文将介绍 TCC（Try-Confirm-Cancel）模式——一种参考 2PC 思想、但不依赖全局锁的分布式事务方案。你将了解到：

TCC 的核心思想和三阶段工作流程
TCC 架构设计及其与 2PC 的对比
用资金转账场景演示 TCC 的完整实现
6 个实现中必须解决的关键问题及其解决方案

前置知识

阅读本文需要了解以下概念（不熟悉也没关系，文中会配合上下文说明）：

分布式事务：跨多个服务或数据库的事务操作，需要保证数据一致性
最终一致性：允许数据在短时间内不一致，但保证最终会达到一致状态
幂等性：同一操作执行一次和多次产生的效果相同

方案或原理

TCC 是什么

TCC（Try-Confirm-Cancel）是一种基于业务补偿的分布式事务解决方案。它将一个完整的业务操作拆分为三个阶段：

阶段	职责	说明
Try	资源预留 / 可行性检查	冻结资源、检查前置条件，但不真正执行业务
Confirm	确认提交	真正执行业务操作，使用 Try 阶段预留的资源
Cancel	取消回滚	释放 Try 阶段预留的资源，恢复到操作前状态

核心思想：不依赖数据库全局锁，而是通过"资源预留 + 显式确认/取消"来控制事务状态。

TCC 本质上是一个带重试、可回滚的分布式状态机。

TCC vs 2PC

两者都采用"两阶段"的思想，但有本质区别：

维度	2PC	TCC
锁机制	数据库全局锁	业务层面资源预留（无全局锁）
实现层面	数据库 / 中间件	业务代码（每个服务实现 Try/Confirm/Cancel）
性能	同步阻塞，资源锁定时间长	无全局锁，并发性能好
侵入性	对业务代码侵入低	需要业务代码配合实现三个阶段
适用场景	对一致性要求极高	高并发、短事务场景

简单来说：2PC 让数据库来管锁，TCC 让业务代码自己管资源。

TCC 架构

核心组件：

事务管理器（TM）：发起分布式事务，决定全局提交或回滚
事务协调器（TC）：协调各分支事务的 Try/Confirm/Cancel 执行
参与者（RM）：各业务服务，实现 Try/Confirm/Cancel 三个接口

TCC 通用流程

flowchart TD
 A[发起分布式事务] --> B[Try 阶段: 资源预留/检查]
 B --> C{所有Try执行成功?}

 C -- 全部成功 --> D[Confirm 阶段: 真正提交执行]
 D --> E[事务完成]

 C -- 部分失败 --> F[Cancel 阶段: 回滚/释放资源]
 F --> G[事务回滚完成]

事务管理器发起分布式事务
Try 阶段：所有参与者执行资源预留和可行性检查
如果所有 Try 都成功，进入 Confirm 阶段，提交业务操作
如果任何一个 Try 失败，进入 Cancel 阶段，释放资源并回滚

优缺点

优势：

性能高：避免数据库长事务与全局锁
隔离性好：资源预留后对其他事务不可见
保证最终一致性，支持回滚操作

代价：

实现复杂：每个业务需要实现三个接口
对幂等要求极高：网络重试可能导致重复调用

适用场景

高并发、短事务：如电商下单、支付冻结
对一致性要求高：如金融交易
不适合长事务：资源会被长期冻结，影响系统性能

实现步骤

下面通过一个资金转账场景（A 账户向 B 账户转账 100 元）演示 TCC 的完整实现。

场景分析

涉及两个服务：

转出服务：从 A 账户扣款
转入服务：向 B 账户加款

1. Try 阶段：资源预留

Try 阶段不是真正扣款/加款，而是"冻结"对应金额。

// 转出服务 - Try：冻结 A 账户 100 元
public boolean tryDeduct(String txId, String accountId, BigDecimal amount) {
 // 检查余额是否充足
 Account account = accountDao.findById(accountId);
 if (account.getBalance().compareTo(amount) < 0) {
 throw new InsufficientBalanceException("余额不足");
 }

 // 冻结金额（可用余额减少，冻结金额增加）
 accountDao.freeze(accountId, amount);

 // 记录事务日志（幂等控制）
 transactionLogDao.save(new TransactionLog(txId, "TRY", accountId));
 return true;
}

// 转入服务 - Try：预增加 B 账户 100 元（标记为待确认）
public boolean tryAdd(String txId, String accountId, BigDecimal amount) {
 // 预增加金额（标记为冻结状态，不可用）
 accountDao.preAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "TRY", accountId));
 return true;
}

关键点：Try 阶段通过"冻结"实现资源预留，而非真正执行业务。

2. Confirm 阶段：确认提交

所有 Try 成功后，执行真正的业务操作。

// 转出服务 - Confirm：真正扣除冻结金额
public boolean confirmDeduct(String txId, String accountId, BigDecimal amount) {
 // 幂等检查：是否已执行过
 if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
 }

 // 扣除冻结金额
 accountDao.deductFrozen(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CONFIRM", accountId));
 return true;
}

// 转入服务 - Confirm：将预增加金额转为可用
public boolean confirmAdd(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
 }

 accountDao.confirmPreAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CONFIRM", accountId));
 return true;
}

3. Cancel 阶段：回滚释放

任何一个 Try 失败时，所有参与者执行 Cancel 释放资源。

// 转出服务 - Cancel：解冻金额
public boolean cancelDeduct(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CANCEL")) {
 return true;
 }

 // 空回滚检查：Try 是否执行过
 if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
 }

 // 解冻金额
 accountDao.unfreeze(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

// 转入服务 - Cancel：撤销预增加
public boolean cancelAdd(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CANCEL")) {
 return true;
 }

 if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
 }

 accountDao.cancelPreAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

注意每个 Cancel 方法都包含了幂等检查和空回滚检查——这是 TCC 实现中最关键的两个防护机制。

示例 / 踩坑

TCC 的核心难点不在"正常流程"，而在各种异常场景下的正确处理。以下是 6 个实现中必须解决的问题。

1. 幂等问题

问题：网络超时后协调器会重试 Confirm/Cancel，可能导致同一操作被执行多次。例如：已经扣款的账户被再次扣款。

解决：

唯一事务 ID：每次操作携带全局唯一的事务 ID
事务状态日志：执行前检查该事务 ID 是否已执行过当前阶段
数据库防重：通过唯一索引防止重复提交

每个 Confirm/Cancel 方法的开头都要做幂等检查：

if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
}

2. 空回滚

问题：Try 请求因网络丢包未到达参与者，但协调器因超时触发 Cancel。此时参与者的 Cancel 没有对应的 Try 操作，执行回滚逻辑会导致数据错误。

解决：

Cancel 执行前检查 Try 是否已执行（查询事务日志）
如果 Try 未执行，直接记录日志并返回成功，不执行业务逻辑

// 空回滚检查
if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

3. 悬挂事务

问题：Try 请求网络延迟，Cancel 已经先于 Try 到达并完成（触发了空回滚）。随后延迟的 Try 才到达并执行成功，资源被冻结但无人推进事务——形成"悬挂"。

解决：

定时轮询监控：后台任务周期扫描，识别长时间停留在 Try 阶段的事务并主动推进
MQ 异步补偿：通过消息队列异步触发后续 Confirm/Cancel 操作，解耦并保障执行可靠性

4. 补偿失败

问题：自动补偿机制可能失效（如数据库宕机、代码 Bug），需要人工介入保证数据一致性。

解决：

预留补偿接口：为 Try/Confirm/Cancel 分别提供可手动触发的补偿接口
事务状态查询接口：供运维人员查询事务当前状态，判断是否需要补偿
补偿任务调度：定时扫描未完成的事务分支，自动重试补偿

5. 超时处理

问题：受网络分区、服务宕机等影响，事务长期滞留于 Try 阶段，无法正常推进。

解决：设置事务超时时间，超时后自动标记为失败，触发 Cancel 回滚。

6. 协调者故障

问题：事务协调器是 TCC 的核心组件，一旦故障，所有进行中的事务都无法推进。

解决：

协调器集群部署，主节点故障后备用节点接管
提供管理后台，允许运维人员手动决定提交或回滚
持久化事务日志，恢复后可继续推进未完成的事务

常见 TCC 组件

组件	语言	特点
Apache Seata	Java	功能全面，支持 AT/TCC/Saga/XA 四种模式
DTM	Go	支持多语言 SDK，轻量级
rust-tcc	Rust	轻量级 TCC 实现

总结

本文介绍了 TCC 分布式事务模式的核心思想和实践方法，回顾要点：

核心思路：将事务拆分为 Try（资源预留）、Confirm（确认提交）、Cancel（取消回滚）三个阶段，通过业务补偿代替全局锁
与 2PC 的区别：TCC 在业务层面控制资源而非依赖数据库锁，性能更好但实现更复杂
关键实现挑战：幂等性、空回滚、悬挂事务、补偿失败、超时处理、协调者故障——每个都需要针对性的解决方案
适用场景：高并发短事务（电商下单、支付冻结），不适合长事务

TCC 不是银弹。如果你的系统事务简单、并发不高，可以考虑更轻量的方案（如本地消息表）。当系统确实面临"分布式事务 + 高并发"的瓶颈时，TCC 是一个值得投入的解决方案。

使用 CQRS 处理读写分离架构

Tue, 05 May 2026 10:00:00 +0800

背景 & 问题

在传统架构中，单个数据模型通常兼顾读和写的职责。但随着系统规模扩展，读和写操作在性能和扩展性上呈现出明显的不对称性：

数据表示不匹配：写入时需要的字段结构与读取时需要的展示形式往往不同。例如，创建订单需要商品 ID 列表，但查询订单详情时用户希望看到商品名称和价格
锁竞争严重：读操作和写操作共享同一份数据，复杂查询（join / 聚合 / 过滤）会长时间占用连接，阻塞写操作
性能无法兼顾：写入追求强一致性和事务安全，读取追求高并发和低延迟，两者的优化方向天然矛盾

这些问题的本质是：单一数据模型无法同时高效满足读与写需求。

本文将介绍 CQRS（Command Query Responsibility Segregation）模式，说明它如何通过读写职责分离来解决上述问题，并给出从简单到复杂的三种演进方案和完整的电商订单系统案例。

前置知识

阅读本文需要了解以下概念（不熟悉也没关系，文中会配合上下文说明）：

领域驱动设计（DDD）：一种以业务领域为核心组织代码的方法论，强调领域模型和业务规则的封装
领域模型（Domain Model）：面向业务的对象模型，包含实体、值对象和聚合根，封装业务规则
领域事件（Domain Event）：表示领域中发生的重要事情（如"订单已创建"），用于解耦不同模块之间的通信
聚合根（Aggregate Root）：一组相关对象的入口点，保证业务规则的一致性边界

方案或原理

CQRS 是什么

CQRS（Command Query Responsibility Segregation）是一种架构模式，核心思想是：将修改数据的操作（Command）和读取数据的操作（Query）彻底解耦，使用不同的模型、流程和存储来分别服务。

简单来说，就是让"写"和"读"各走各的路，各自优化。

优缺点

优势：

写操作聚焦强一致性和业务规则，读操作聚焦高并发和数据展示
读写可独立扩容，读模型可以使用缓存、搜索引擎等专门优化
降低单个模型的复杂度，职责更清晰

代价：

需要维护两套模型，开发成本和学习成本增加
读模型通常异步更新，存在数据延迟（最终一致性）
事件同步、消息队列等基础设施需要额外运维

适用场景

场景	说明
读多写少	用户频繁查询但写入较少，如电商订单查询
查询逻辑复杂	需要多表 join、聚合计算，如报表系统
读写性能要求差异大	写要求强一致，读要求低延迟高并发
业务逻辑复杂	领域规则复杂，不适合在查询中混入业务逻辑

如果你的系统读写都很简单，或者读远大于写但查询也不复杂，引入 CQRS 可能是过度设计。先评估实际需求，再决定是否采用。

五个设计原则

1. 读写职责分离

写操作只负责修改状态 + 执行业务规则
读操作只负责数据获取 + 展示优化
禁止在 Query 中修改状态

目的：避免读路径被业务逻辑污染，也保证查询可独立优化。

2. 一致性策略明确

写路径：强一致（通过事务和聚合保证）
读路径：最终一致（允许短暂延迟）

必须根据业务定义"可接受延迟范围"。例如：订单创建后 1 秒内可在查询中看到，这通常是可接受的。

目的：用"可控不一致"换取系统性能与扩展性。

3. 模型分离

写模型（Domain Model）：面向业务规则与一致性
读模型（Read Model）：面向查询与展示，可以反范式化（去范式化）以提高查询效率

读模型不需要与数据库表结构一致，它只为查询服务。

目的：避免一个模型同时承担"复杂业务 + 高性能查询"两种职责。

4. 存储分离

写存储：事务型数据库（如 MySQL），保证强一致性
读存储：缓存（如 Redis）/ 搜索引擎（如 ElasticSearch）/ 副本库

是否拆分存储取决于读压力与查询复杂度，并非所有场景都需要物理分离。

目的：让存储层也服务于不同的优化目标。

5. 异步解耦

通过领域事件（Domain Event）连接读写模型
流程：写操作 → 发布事件 → 异步更新读模型（Projection）

需要接受最终一致性（存在延迟）。

目的：降低系统耦合，支持独立扩展读模型。

CQRS 架构概览

┌─────────────┐ Command ┌──────────────────┐ Event ┌──────────────────┐
│ Client │ ──────────────→ │ Command Handler │ ─────────────→ │ Event Handler │
│ │ │ (写流程编排) │ │ (Projection) │
└─────────────┘ └────────┬─────────┘ └────────┬─────────┘
 │ │
 ▼ ▼
 ┌──────────────┐ ┌──────────────┐
 │ Write Store │ │ Read Store │
 │ (MySQL) │ │ (Redis/ES) │
 └──────────────┘ └──────────────┘
 ▲
┌─────────────┐ Query ┌──────────────────┐ │
│ Client │ ──────────────→ │ Query Handler │ ───────────────────┘
│ │ │ (读流程编排) │
└─────────────┘ └──────────────────┘

实现步骤

CQRS 并不是一步到位的，可以根据系统复杂度分三个层次渐进式引入。不必一上来就用最复杂的方案。

Level 1：逻辑分离（单库）

思路：仍然使用单个数据库，只在代码层面分离读和写。

做法：

代码中分为 Command 对象和 Query 对象
写操作使用 Domain Model，读操作使用独立的 Read Model（DTO / VO）
共享同一个数据库，读模型可以通过 SQL 视图或简单映射得到

适用场景：系统初期，读写压力都不大，但希望代码职责清晰。

优点：改动最小，风险最低局限：读和写仍然竞争同一份数据库资源

Level 2：物理分离（双库）

思路：将数据库分为写库和读库，读库独立优化。

做法：

写库（MySQL 主库）：处理所有写操作，保证强一致性
读库（MySQL 从库 / Redis / ElasticSearch）：处理所有读操作
写库数据通过主从复制或同步机制同步到读库

适用场景：读多写少，查询逻辑较复杂，读操作需要独立扩容。

优点：读写不竞争数据库资源，读库可针对性优化局限：需要维护数据同步机制，存在同步延迟

Level 3：事件驱动（Event Sourcing + CQRS）

思路：写路径产生的状态变化抽象为领域事件（Domain Event），由 Event Handler 异步构建和更新 Read Model。

做法：

写操作修改 Domain Model 后，发布领域事件
Event Handler 监听事件，将数据转换为读模型需要的格式，写入 Read Store
读操作直接查询 Read Store，完全不访问 Write Store

适用场景：业务逻辑复杂，需要完整的审计日志，或需要多个读模型服务不同查询场景。

优点：读写完全解耦，可灵活构建多个专用读模型局限：架构最复杂，需要事件基础设施（消息队列），调试难度最高

三种层次对比

维度	L1 逻辑分离	L2 物理分离	L3 事件驱动
存储数量	1 个	2 个	2+ 个
代码改动	小	中	大
读写解耦程度	低	中	高
一致性	强一致	最终一致（秒级延迟）	最终一致（毫秒~秒级延迟）
基础设施要求	无	主从复制 / 同步工具	消息队列 + Event Store
适用阶段	项目初期	系统成长期	大型复杂系统

示例 / 踩坑

下面通过一个电商订单系统，演示 CQRS Level 3（事件驱动）的完整实现。

业务场景

电商订单系统，核心需求：

写：创建订单、支付、取消（要求强一致性和复杂业务规则校验）
读：订单列表、订单详情（用户频繁查询，需要低延迟）
特点：读多写少，查询涉及多表 join 和聚合计算

CQRS 改造思路

写（Command）：CreateOrder → OrderAggregate → MySQL
读（Query）：GetOrderDetail → Redis / Read DB（预聚合数据）
连接：OrderCreatedEvent → Event Handler 异步更新 Read Model

代码实现

Command：写路径的输入模型

public class CreateOrderCommand {
 private Long userId;
 private List<Long> productIds;

 // 构造方法 / getter
}

Domain Model：核心领域对象

public class Order {
 private Long id;
 private Long userId;
 private List<Long> productIds;
 private String status;

 public static Order create(Long userId, List<Long> productIds) {
 if (productIds == null || productIds.isEmpty()) {
 throw new IllegalArgumentException("商品不能为空");
 }

 Order order = new Order();
 order.userId = userId;
 order.productIds = productIds;
 order.status = "CREATED";
 return order;
 }
}

Command Handler：写流程编排

public class CreateOrderHandler {

 private OrderRepository repository;
 private EventPublisher eventPublisher;

 public Long handle(CreateOrderCommand cmd) {
 // 1. 构建领域对象（业务规则校验在 create 方法中）
 Order order = Order.create(cmd.getUserId(), cmd.getProductIds());

 // 2. 持久化（事务保证强一致性）
 repository.save(order);

 // 3. 发布事件（异步更新读模型）
 eventPublisher.publish(new OrderCreatedEvent(order.getId()));

 return order.getId();
 }
}

Read Model：读模型（专为查询设计）

public class OrderView {
 private Long orderId;
 private String status;
 private List<String> productNames;
 private BigDecimal totalPrice;

 // getter
}

注意读模型和写模型的区别：写模型存储 productIds（商品 ID），读模型存储 productNames（商品名称）和 totalPrice（总价）——这是面向查询优化的结果。

Query Handler：读流程编排

public class GetOrderDetailHandler {

 private OrderReadRepository readRepository;

 public OrderView handle(Long orderId) {
 // 直接查缓存或 Read DB，无业务逻辑
 return readRepository.findById(orderId);
 }
}

Event Handler：投影器（Projection）

Projection 监听领域事件，将 Command Side 的数据转换为 Read Model 并持久化：

public class OrderProjectionHandler {

 private OrderReadRepository readRepository;
 private ProductRepository productRepository;

 public void on(OrderCreatedEvent event) {

 List<String> productNames =
 productRepository.findNames(event.getProductIds());

 OrderView view = new OrderView();
 view.setOrderId(event.getOrderId());
 view.setStatus(event.getStatus());
 view.setProductNames(productNames);

 readRepository.save(view);
 }
}

常见问题与踩坑

问题 1：读模型更新延迟导致用户看不到最新数据

这是 CQRS 最常见的问题。用户刚创建订单，立刻查询却找不到。

解决方案：

前端在写操作成功后，短暂轮询或使用 WebSocket 等待读模型更新
在读模型未就绪时，回退到写库查询（Fallback 策略）
在 UI 上提示用户"数据正在同步中"

问题 2：事件处理失败导致读写数据不一致

Event Handler 处理事件时可能失败（网络抖动、数据库异常等），导致读模型缺失数据。

解决方案：

事件消费必须实现幂等性，重复消费不会产生副作用
使用消息队列的重试机制（如 RabbitMQ 的 Dead Letter Queue）
定期做数据对账，比对写库和读库的数据差异并修复

问题 3：读模型结构变更困难

业务变化导致读模型需要新增字段，但历史事件中不包含这些字段。

解决方案：

新增字段设置默认值，避免历史数据缺失
设计事件时采用"事件增量"模式，通过版本号管理字段变更
需要时可以发起全量重建（Rebuild）读模型

问题 4：过度设计

并非所有系统都需要 CQRS。如果读写逻辑简单、并发量不大，引入 CQRS 反而增加不必要的复杂度。

判断标准：当你的系统确实面临"读写性能无法兼顾"的瓶颈时，再考虑引入。

总结

本文介绍了 CQRS 模式的核心思想和实践方法，回顾要点：

核心思路：将 Command（写）和 Query（读）解耦，各自优化
五个设计原则：读写职责分离、一致性策略明确、模型分离、存储分离、异步解耦
三种演进层次：逻辑分离 → 物理分离 → 事件驱动，根据系统复杂度渐进式引入
关键取舍：用最终一致性换取读写性能和扩展性

CQRS 不是银弹，它解决的是"读写性能无法兼顾"这一类特定问题。如果你的系统面临这个瓶颈，可以从 Level 1（逻辑分离）开始，渐进式演进到更复杂的方案。

CAP 定理：分布式系统的权衡

Mon, 16 Mar 2026 13:00:00 +0800

CAP 定理

CAP 定理指出，分布式系统最多只能同时满足以下三个特性中的两个：

一致性 (Consistency)

所有节点在同一时间看到相同的数据。

可用性 (Availability)

每个请求都能得到响应（成功或失败），保证系统持续服务。

分区容错性 (Partition Tolerance)

系统在网络分区的情况下仍能继续运行。

三种权衡组合

组合	说明	典型系统
CA	放弃分区容错	单机数据库（RDBMS）
CP	放弃可用性	HBase, MongoDB, Redis
AP	放弃强一致性	Cassandra, DynamoDB

BASE 理论

CAP 的替代方案：

Basically Available：基本可用
Soft state：软状态
Eventually consistent：最终一致性

总结

在设计分布式系统时，需要根据业务场景选择合适的权衡：

金融交易：优先保证一致性（CP）
社交媒体：优先保证可用性（AP）