分布式事务实现方式详解

原创于 2025-12-04 16:24:26 发布 · 354 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#分布式 #事务

Architect 专栏收录该内容

11 篇文章

订阅专栏

分布式事务实现方式详解

引言

在分布式系统中，事务管理是一个核心挑战。传统的单机事务ACID特性（原子性、一致性、隔离性、持久性）在分布式环境下变得复杂。分布式事务需要协调多个服务、数据库或消息队列的操作，确保数据的一致性。

本文将详细介绍当前主流的分布式事务实现方式，分析各自的优缺点和适用场景，帮助开发者选择合适的解决方案。

分布式事务基础概念

什么是分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，就是一个操作需要跨多个服务或数据库完成。

CAP理论

在分布式系统中，CAP理论指出：

C (Consistency): 一致性，所有节点在同一时间具有相同的数据
A (Availability): 可用性，保证每个请求都有响应
P (Partition tolerance): 分区容错性，系统中任意信息的丢失或失败不会影响系统的继续运作

分布式系统无法同时满足CAP三个特性，最多只能满足其中两个。

BASE理论

BASE理论是对CAP理论的延伸：

BA (Basically Available): 基本可用
S (Soft state): 软状态
E (Eventually consistent): 最终一致性

BASE理论通过牺牲强一致性来获得高可用性。

两阶段提交（2PC）

原理概述

两阶段提交（Two-Phase Commit）是最经典的分布式事务协议，分为准备阶段和提交阶段。

第一阶段：准备阶段

事务协调者向所有参与者发送prepare请求
参与者执行事务操作，但不提交
参与者将undo和redo信息记录到事务日志
参与者向协调者返回准备就绪或失败响应

第二阶段：提交阶段

情况一：所有参与者都准备就绪

协调者向所有参与者发送commit请求
参与者正式提交事务
参与者释放事务占用的资源
参与者向协调者发送ack确认

情况二：有参与者准备失败

协调者向所有参与者发送rollback请求
参与者利用undo日志回滚事务
参与者释放事务占用的资源
参与者向协调者发送ack确认

优缺点分析

优点：

实现简单，理解容易
保证强一致性
广泛应用，有成熟实现

缺点：

同步阻塞，性能较差
单点故障风险（协调者）
数据不一致风险（第二阶段协调者故障）
网络分区问题

适用场景

对一致性要求极高的场景
参与者数量较少
网络环境稳定
性能要求不高

代码示例

// 2PC协调者实现示例
public class TwoPhaseCommitCoordinator {
    private List<Participant> participants;
    
    public boolean executeTransaction(Transaction transaction) {
        // 第一阶段：准备
        List<Participant> readyParticipants = new ArrayList<>();
        
        for (Participant participant : participants) {
            try {
                if (participant.prepare(transaction)) {
                    readyParticipants.add(participant);
                } else {
                    // 有参与者准备失败，回滚所有已准备的参与者
                    rollbackParticipants(readyParticipants, transaction);
                    return false;
                }
            } catch (Exception e) {
                rollbackParticipants(readyParticipants, transaction);
                return false;
            }
        }
        
        // 第二阶段：提交
        for (Participant participant : readyParticipants) {
            try {
                participant.commit(transaction);
            } catch (Exception e) {
                // 记录日志，需要人工干预
                logError("Commit failed for participant: " + participant, e);
            }
        }
        
        return true;
    }
    
    private void rollbackParticipants(List<Participant> participants, Transaction transaction) {
        for (Participant participant : participants) {
            try {
                participant.rollback(transaction);
            } catch (Exception e) {
                logError("Rollback failed for participant: " + participant, e);
            }
        }
    }
}

三阶段提交（3PC）

原理概述

三阶段提交（Three-Phase Commit）是对2PC的改进，增加了预提交阶段，减少了阻塞时间。

三个阶段

第一阶段：CanCommit

协调者向参与者发送CanCommit请求
参与者检查自身状态，返回Yes或No

第二阶段：PreCommit

如果所有参与者都返回Yes，协调者发送PreCommit请求
参与者执行事务操作，记录undo/redo日志
参与者返回ACK或No

第三阶段：DoCommit

如果收到所有ACK，协调者发送DoCommit请求
参与者提交事务
如果有参与者返回No或超时，发送abort请求

与2PC的区别

减少阻塞：在PreCommit阶段后，参与者可以超时提交
单点故障处理更好：协调者故障时，参与者可以自主决策
网络分区容忍性更好

优缺点分析

优点：

减少阻塞时间
更好的容错性
单点故障影响较小

缺点：

实现复杂
网络开销更大
仍然无法完全解决数据不一致问题

适用场景

对可用性要求较高的场景
网络环境相对复杂
参与者数量适中

TCC模式（Try-Confirm-Cancel）

原理概述

TCC（Try-Confirm-Cancel）是一种补偿型事务模式，将事务分为三个阶段：

Try阶段：尝试执行业务，完成所有业务检查，预留必需的业务资源
Confirm阶段：确认执行业务，真正执行业务，不作任何业务检查
Cancel阶段：取消执行业务，释放预留的业务资源

实现机制

// TCC事务接口定义
public interface TccTransaction {
    /**
     * Try阶段：资源检查和预留
     */
    boolean tryExecute(BusinessContext context);
    
    /**
     * Confirm阶段：确认执行
     */
    boolean confirm(BusinessContext context);
    
    /**
     * Cancel阶段：取消执行，释放资源
     */
    boolean cancel(BusinessContext context);
}

业务场景示例

以转账业务为例：

Try阶段：

检查账户余额是否充足
冻结转账金额
记录事务日志

Confirm阶段：

扣减账户余额
增加目标账户余额
清除冻结金额

Cancel阶段：

释放冻结金额
清除事务日志

优缺点分析

优点：

性能较好，无长期锁
业务逻辑清晰
支持高并发
容错性好

缺点：

业务侵入性强
需要实现补偿逻辑
设计复杂度高
可能出现补偿失败

适用场景

高并发场景
业务逻辑相对简单
可以接受最终一致性
有明确的补偿机制

框架实现

// TCC框架实现示例
@Component
public class TccTransactionManager {
    
    @Autowired
    private TccTransactionLogDao transactionLogDao;
    
    public boolean executeTccTransaction(TccTransaction transaction, BusinessContext context) {
        String transactionId = generateTransactionId();
        
        try {
            // Try阶段
            if (!transaction.tryExecute(context)) {
                return false;
            }
            
            // 记录事务日志
            recordTransactionLog(transactionId, "TRY", "SUCCESS");
            
            // Confirm阶段
            if (!transaction.confirm(context)) {
                // Confirm失败，执行Cancel
                transaction.cancel(context);
                recordTransactionLog(transactionId, "CONFIRM", "FAILED");
                return false;
            }
            
            recordTransactionLog(transactionId, "CONFIRM", "SUCCESS");
            return true;
            
        } catch (Exception e) {
            // 异常时执行Cancel
            try {
                transaction.cancel(context);
                recordTransactionLog(transactionId, "CANCEL", "SUCCESS");
            } catch (Exception cancelException) {
                recordTransactionLog(transactionId, "CANCEL", "FAILED");
                // 记录需要人工处理的异常
                alertManualIntervention(transactionId, cancelException);
            }
            return false;
        }
    }
}

Saga模式

原理概述

Saga模式将一个分布式事务拆分为多个本地事务，每个本地事务都有对应的补偿操作。如果某个步骤失败，则执行前面所有步骤的补偿操作。

Saga的两种实现方式

1. 编排式（Choreography）

没有中央协调器
每个服务订阅事件，自动执行
通过事件总线进行通信

2. 控制式（Orchestration）

有中央协调器
协调器控制整个流程
服务之间不直接通信

Saga执行流程

正常流程： T1 → T2 → T3 → T4
失败补偿： T1 → T2 → T3(失败) → C2 → C1

代码示例

// Saga事务定义
public class SagaTransaction {
    private List<SagaStep> steps;
    
    public SagaTransaction(List<SagaStep> steps) {
        this.steps = steps;
    }
    
    public boolean execute() {
        List<SagaStep> executedSteps = new ArrayList<>();
        
        for (SagaStep step : steps) {
            try {
                step.execute();
                executedSteps.add(step);
            } catch (Exception e) {
                // 执行补偿操作
                compensate(executedSteps);
                return false;
            }
        }
        
        return true;
    }
    
    private void compensate(List<SagaStep> executedSteps) {
        // 逆序执行补偿操作
        Collections.reverse(executedSteps);
        
        for (SagaStep step : executedSteps) {
            try {
                step.compensate();
            } catch (Exception e) {
                // 记录补偿失败，需要人工干预
                log.error("Compensation failed for step: " + step, e);
            }
        }
    }
}

// Saga步骤定义
public interface SagaStep {
    void execute() throws Exception;
    void compensate() throws Exception;
}

优缺点分析

优点：

无长期锁，性能好
业务逻辑清晰
支持复杂业务流程
容错性好

缺点：

实现复杂
补偿逻辑设计困难
可能出现补偿失败
数据一致性是最终一致性

适用场景

业务流程较长
涉及多个服务
可以接受最终一致性
有明确的业务补偿逻辑

本地消息表

原理概述

本地消息表方案通过在本地数据库中维护一个消息表，确保本地事务和消息发送的原子性。

实现机制

业务操作和消息记录在同一个本地事务中
后台任务轮询消息表并发送消息
消息消费者处理消息后发送确认
收到确认后删除或标记消息为已处理

架构图

生产者：
┌─────────────────┐
│   业务操作       │
└────────┬────────┘
         │
┌────────▼────────┐
│ 本地事务         │
├─────────────────┤
│ 1. 业务数据操作  │
│ 2. 消息表插入    │
└─────────────────┘
         │
         ▼
┌─────────────────┐
│ 消息发送服务     │
└─────────────────┘

消费者：
┌─────────────────┐
│   消息处理       │
└────────┬────────┘
         │
┌────────▼────────┐
│ 业务处理         │
└─────────────────┘

代码示例

// 本地消息表实现
@Service
public class LocalMessageTransactionService {
    
    @Autowired
    private BusinessDao businessDao;
    
    @Autowired
    private MessageDao messageDao;
    
    @Autowired
    private MessageSender messageSender;
    
    @Transactional
    public void executeBusinessWithMessage(BusinessRequest request, Message message) {
        // 执行业务操作
        businessDao.insertBusinessData(request);
        
        // 记录消息到本地消息表
        messageDao.insertMessage(message);
        
        // 事务提交后，消息表和业务数据同时成功或失败
    }
    
    // 定时任务发送消息
    @Scheduled(fixedDelay = 5000)
    public void sendMessages() {
        List<Message> pendingMessages = messageDao.findPendingMessages();
        
        for (Message message : pendingMessages) {
            try {
                // 发送消息到MQ
                messageSender.send(message);
                
                // 更新消息状态为已发送
                messageDao.updateMessageStatus(message.getId(), "SENT");
            } catch (Exception e) {
                log.error("Failed to send message: " + message.getId(), e);
                // 消息保持待发送状态，下次重试
            }
        }
    }
}

优缺点分析

优点：

实现简单
不依赖特定MQ
可靠性强
支持最终一致性

缺点：

需要额外的消息表
需要轮询机制
实时性较差
增加数据库压力

适用场景

对实时性要求不高
已有数据库系统
需要可靠消息传递
可以接受最终一致性

MQ事务消息

原理概述

MQ事务消息利用消息队列的事务特性，确保消息发送和业务操作的一致性。

实现机制（以RocketMQ为例）

发送半消息：发送prepare消息，此时消息对消费者不可见
执行本地事务：执行本地业务逻辑
提交或回滚：根据本地事务执行结果，提交或回滚半消息
回查机制：如果长时间未收到提交/回滚指令，MQ会主动回查

代码示例

// RocketMQ事务消息实现
@Component
public class TransactionMessageProducer {
    
    @Autowired
    private TransactionMQProducer producer;
    
    @Autowired
    private BusinessService businessService;
    
    public void sendTransactionMessage(Message message, BusinessRequest request) {
        // 发送事务半消息
        TransactionSendResult result = producer.sendMessageInTransaction(message, request);
        
        if (result.getLocalTransactionState() == LocalTransactionState.UNKNOW) {
            // 需要等待回查结果
            log.info("Transaction message status unknown, waiting for check");
        }
    }
    
    // 事务监听器
    @Component
    public class TransactionListenerImpl implements TransactionListener {
        
        @Override
        public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
            try {
                // 执行本地事务
                BusinessRequest request = (BusinessRequest) arg;
                businessService.processBusiness(request);
                
                // 本地事务成功，提交消息
                return LocalTransactionState.COMMIT_MESSAGE;
            } catch (Exception e) {
                // 本地事务失败，回滚消息
                return LocalTransactionState.ROLLBACK_MESSAGE;
            }
        }
        
        @Override
        public LocalTransactionState checkLocalTransaction(MessageExt msg) {
            // 回查本地事务状态
            String transactionId = msg.getTransactionId();
            boolean transactionExists = businessService.checkTransaction(transactionId);
            
            if (transactionExists) {
                return LocalTransactionState.COMMIT_MESSAGE;
            } else {
                return LocalTransactionState.ROLLBACK_MESSAGE;
            }
        }
    }
}

优缺点分析

优点：

实现相对简单
性能好
实时性高
支持最终一致性

缺点：

依赖特定MQ实现
需要处理回查逻辑
消息可能重复消费
需要幂等处理

适用场景

需要高实时性
已有MQ基础设施
可以接受最终一致性
业务逻辑相对简单

Seata框架实现

Seata简介

Seata是阿里巴巴开源的分布式事务解决方案，提供了AT、TCC、Saga和XA四种事务模式。

AT模式（Auto Transaction）

AT模式是Seata的默认模式，基于两阶段提交，但对业务无侵入。

实现原理

一阶段：执行业务SQL，Seata自动生成分支事务的反向SQL
二阶段：
- 成功：异步清理回滚日志
- 失败：通过回滚日志进行补偿

代码示例

// Seata AT模式使用
@Service
public class OrderService {
    
    @GlobalTransactional(name = "create-order", rollbackFor = Exception.class)
    public void createOrder(Order order) {
        // 本地事务1：扣减库存
        storageService.deduct(order.getProductId(), order.getCount());
        
        // 本地事务2：创建订单
        orderDao.insert(order);
        
        // 本地事务3：扣减账户余额
        accountService.deduct(order.getUserId(), order.getMoney());
    }
}

// 只需要在业务方法上添加@GlobalTransactional注解

TCC模式

Seata的TCC模式需要业务方实现Try、Confirm、Cancel三个接口。

// Seata TCC模式实现
@LocalTCC
public interface TccAccountService {
    
    @TwoPhaseBusinessAction(name = "deductTcc", commitMethod = "confirm", rollbackMethod = "cancel")
    boolean prepare(@BusinessActionContextParameter(paramName = "userId") String userId,
                    @BusinessActionContextParameter(paramName = "amount") BigDecimal amount);
    
    boolean confirm(BusinessActionContext context);
    
    boolean cancel(BusinessActionContext context);
}

Saga模式

Seata的Saga模式通过状态机来编排事务。

// Saga状态机配置
@JsonIgnoreProperties(ignoreUnknown = true)
public class SagaStateMachine {
    
    private String name;
    private String comment;
    private List<State> states;
    
    // 状态定义
    public static class State {
        private String name;
        private String type;
        private String serviceName;
        private String serviceMethod;
        private String compensationMethod;
        private List<Transition> transitions;
    }
}

Seata架构

┌─────────────────┐
│   TM (事务管理器) │
└────────┬────────┘
         │
┌────────▼────────┐
│   TC (事务协调器) │
└────────┬────────┘
         │
┌────────▼────────┐     ┌─────────────────┐
│   RM (资源管理器) │─────│   业务服务       │
└─────────────────┘     └─────────────────┘

优缺点分析

优点：

多种事务模式可选
对业务侵入性小（AT模式）
社区活跃，文档完善
性能较好

缺点：

需要部署Seata Server
学习成本较高
增加了系统复杂度
需要维护回滚日志

适用场景

微服务架构
需要多种事务模式
对一致性有要求
可以接受一定的性能损耗

方案对比与选择

对比表格

方案	一致性	性能	复杂度	业务侵入性	适用场景
2PC	强一致性	低	中	低	一致性要求高，参与者少
3PC	强一致性	中	高	低	网络环境复杂，可用性要求高
TCC	最终一致性	高	高	高	高并发，业务逻辑简单
Saga	最终一致性	高	高	中	长事务，业务流程复杂
本地消息表	最终一致性	中	低	中	实时性要求不高，已有数据库
MQ事务消息	最终一致性	高	中	中	高实时性，已有MQ
Seata AT	最终一致性	中	中	低	微服务，对一致性有要求