3小时攻克分布式事务难题：Hmily TCC模式从0到生产级实践指南

3小时攻克分布式事务难题：Hmily TCC模式从0到生产级实践指南

【免费下载链接】hmily 金融级分布式事务解决方案 项目地址: https://gitcode.com/dromara/hmily

你是否还在为分布式系统中的数据一致性问题焦头烂额？支付成功但订单状态未更新、库存扣减后订单创建失败导致超卖、退款流程中资金与订单状态不同步——这些典型的分布式事务难题，正在严重影响你的系统稳定性和用户体验。本文将通过金融级分布式事务解决方案Hmily，带你从理论到实践，3小时内彻底掌握TCC (Try-Confirm-Cancel) 模式的实现精髓，轻松解决90%的分布式一致性问题。

读完本文你将获得：

• 分布式事务核心理论与TCC模式工作原理
• Hmily框架的架构设计与核心组件解析
• 从零开始的Spring Cloud + Hmily集成步骤
• 生产级TCC案例完整代码实现（含异常处理）
• 性能优化策略与常见问题解决方案
• 事务监控与运维最佳实践

分布式事务全景图与Hmily定位

在微服务架构中，一个业务流程往往涉及多个独立部署的服务，每个服务维护着自己的数据库。传统的单机事务（ACID）已无法保证跨服务操作的数据一致性，分布式事务应运而生。目前主流的分布式事务解决方案可分为以下几类：

事务模式	核心原理	优势	劣势	适用场景
2PC (两阶段提交)	协调者统一管控所有参与者的提交/回滚	强一致性	性能差、协调者单点风险	短事务、低并发场景
TCC (补偿事务)	业务逻辑拆分为Try-Confirm-Cancel三阶段	高性能、无锁阻塞	侵入业务代码、开发成本高	高并发金融核心场景
SAGA	长事务拆分为本地事务序列，失败则反向补偿	长流程支持好	一致性弱、补偿逻辑复杂	非核心业务长流程
本地消息表	消息日志与业务操作本地事务提交	可靠性高	侵入业务代码、消息表维护成本	异步通信场景
事务消息	MQ中间件保证消息可靠投递与消费	低耦合、高可用	一致性弱、依赖MQ可靠性	非实时一致性场景

Hmily作为Dromara开源社区的金融级分布式事务解决方案，采用柔性事务设计理念，提供TCC和TAC两种核心模式。其架构如图所示：

Hmily的核心优势在于：

• 零侵入性：通过注解和AOP实现事务拦截，业务代码无感知
• 高性能：去中心化设计，事务日志异步写入，吞吐量可达10000+ TPS
• 多语言支持：Java原生支持，通过gRPC可扩展至多语言环境
• 丰富存储：支持MySQL、Redis、MongoDB等多种事务日志存储方案
• 全面监控：Metrics指标监控与Admin管理后台，实时观测事务状态

环境准备与工程搭建

开发环境要求

依赖项	版本要求	备注
JDK	8+	推荐JDK11，支持更好的性能优化
Maven	3.5+	用于依赖管理和项目构建
MySQL	5.7+	存储业务数据与事务日志
Spring Cloud	Greenwich.RELEASE+	微服务框架，本文以Greenwich.SR2为例
Spring Boot	2.1.x.RELEASE+	快速开发脚手架
Hmily	2.1.1+	分布式事务核心框架

源码获取与项目结构

通过GitCode克隆Hmily源码仓库：

git clone https://gitcode.com/dromara/hmily.git
cd hmily

Hmily项目采用模块化设计，核心模块结构如下：

hmily/
├── hmily-annotation/        # 核心注解定义(TCC/TAC)
├── hmily-core/              # 事务协调核心逻辑
├── hmily-repository/        # 事务日志存储实现
├── hmily-rpc/               # RPC框架集成适配
├── hmily-spring-boot-starter/ # Spring Boot自动配置
└── hmily-demo/              # 各类事务模式示例代码

本文将基于hmily-demo-tcc-springcloud模块进行扩展，实现一个完整的订单-库存-账户转账场景的分布式事务。

数据库初始化

执行以下SQL脚本创建必要的业务数据库和表结构：

-- 创建账户数据库
CREATE DATABASE IF NOT EXISTS `hmily_account` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
USE `hmily_account`;

-- 账户表
CREATE TABLE `account` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` varchar(128) NOT NULL COMMENT '用户ID',
  `balance` decimal(10,0) NOT NULL COMMENT '可用余额',
  `freeze_amount` decimal(10,0) NOT NULL COMMENT '冻结金额',
  `create_time` datetime NOT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- 初始化测试账户，余额100000元
INSERT INTO `account` (`user_id`, `balance`, `freeze_amount`, `create_time`) 
VALUES ('10000', 100000, 0, NOW());

-- 创建库存数据库
CREATE DATABASE IF NOT EXISTS `hmily_stock` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
USE `hmily_stock`;

-- 库存表
CREATE TABLE `inventory` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `product_id` varchar(128) NOT NULL COMMENT '商品ID',
  `total_inventory` int(10) NOT NULL COMMENT '总库存',
  `lock_inventory` int(10) NOT NULL COMMENT '锁定库存',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

-- 初始化测试商品库存，10000件
INSERT INTO `inventory` (`product_id`, `total_inventory`, `lock_inventory`) 
VALUES ('1', 10000, 0);

-- 创建订单数据库
CREATE DATABASE IF NOT EXISTS `hmily_order` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
USE `hmily_order`;

-- 订单表
CREATE TABLE `order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) NOT NULL COMMENT '订单编号',
  `user_id` varchar(128) NOT NULL COMMENT '用户ID',
  `product_id` varchar(128) NOT NULL COMMENT '商品ID',
  `amount` decimal(10,0) NOT NULL COMMENT '订单金额',
  `status` tinyint(4) NOT NULL COMMENT '订单状态：0-创建中，1-成功，2-失败',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

项目依赖配置

在Spring Cloud项目的pom.xml中添加Hmily依赖：

<!-- Hmily Spring Cloud Starter -->
<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>hmily-spring-boot-starter-springcloud</artifactId>
    <version>2.1.1</version>
</dependency>

<!-- Hmily 数据库日志存储 -->
<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>hmily-repository-database-mysql</artifactId>
    <version>2.1.1</version>
</dependency>

配置application.yml文件，启用Hmily并配置事务日志存储：

spring:
  application:
    name: order-service
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/hmily_order?useUnicode=true&characterEncoding=utf8&serverTimezone=GMT%2B8
    username: root
    password: root

# Hmily配置
hmily:
  service:
    app-name: ${spring.application.name}
    serializer: kryo # 使用kryo序列化，性能优于默认的hessian
  repository:
    database:
      driver-class-name: com.mysql.cj.jdbc.Driver
      url: jdbc:mysql://localhost:3306/hmily?useUnicode=true&characterEncoding=utf8&serverTimezone=GMT%2B8
      username: root
      password: root
      max-wait: 10000
      max-active: 20
      min-idle: 10
  metrics:
    enabled: true # 启用监控指标
  recover:
    enabled: true # 启用事务恢复
    max-retry-count: 3 # 最大重试次数
    retry-delay: 5000 # 重试延迟(毫秒)

TCC模式核心实现

TCC模式工作原理

TCC模式将分布式事务拆分为三个明确的阶段，通过业务逻辑的拆分实现最终一致性：

1. Try阶段：资源检查与预留。尝试执行业务操作，完成所有业务检查（一致性），预留必须的业务资源（准隔离性）。

2. Confirm阶段：确认执行业务操作。当Try阶段所有参与者均成功，执行实际的业务操作，不做任何业务检查，只使用Try阶段预留的资源。

3. Cancel阶段：取消执行业务操作。当Try阶段有参与者失败，取消已执行的操作，释放Try阶段预留的资源。

TCC模式的关键在于幂等性设计和空回滚防护：

• 幂等性：Confirm/Cancel方法必须支持重复执行，结果一致
• 空回滚：当Try阶段未执行时，Cancel方法应不做任何操作
• 悬挂：Cancel方法先于Try方法执行时，应拒绝执行

Hmily TCC注解详解

Hmily通过@HmilyTCC注解声明TCC事务，核心属性如下：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface HmilyTCC {
    // Confirm方法名称，默认为空
    String confirmMethod() default "";
    
    // Cancel方法名称，默认为空
    String cancelMethod() default "";
    
    // 事务类型，默认为TCC
    TransTypeEnum pattern() default TransTypeEnum.TCC;
}

注解使用规则：

1. Confirm/Cancel方法必须与Try方法在同一个类中
2. 参数列表必须与Try方法完全一致
3. 返回值建议为Boolean类型，便于框架判断执行结果
4. 若事务上下文需要传递，可在参数中添加HmilyTransactionContext

库存服务TCC实现

创建库存服务的TCC实现类，包含Try/Confirm/Cancel三个方法：

@Service
public class InventoryServiceImpl implements InventoryService {
    
    private static final Logger LOGGER = LoggerFactory.getLogger(InventoryServiceImpl.class);
    
    private final InventoryMapper inventoryMapper;
    
    @Autowired
    public InventoryServiceImpl(InventoryMapper inventoryMapper) {
        this.inventoryMapper = inventoryMapper;
    }
    
    /**
     * Try阶段：扣减库存（预冻结）
     */
    @Override
    @HmilyTCC(confirmMethod = "confirm", cancelMethod = "cancel")
    public boolean decrease(InventoryDTO inventoryDTO) {
        LOGGER.info("======库存服务Try阶段：预冻结库存======");
        LOGGER.info("事务ID: {}", HmilyTransactionContextLocal.getInstance().get().getTransId());
        
        // 1. 检查库存是否充足
        InventoryDO inventory = inventoryMapper.findByProductId(inventoryDTO.getProductId());
        if (inventory == null || inventory.getTotalInventory() < inventoryDTO.getCount()) {
            throw new HmilyRuntimeException("库存不足");
        }
        
        // 2. 预冻结库存（更新lock_inventory）
        int affected = inventoryMapper.freezeInventory(inventoryDTO);
        if (affected != 1) {
            throw new HmilyRuntimeException("库存冻结失败");
        }
        return true;
    }
    
    /**
     * Confirm阶段：确认扣减库存
     */
    public boolean confirm(InventoryDTO inventoryDTO) {
        LOGGER.info("======库存服务Confirm阶段：确认扣减库存======");
        
        // 实际扣减库存（total_inventory -= count, lock_inventory -= count）
        int affected = inventoryMapper.confirmDecrease(inventoryDTO);
        if (affected != 1) {
            // 记录告警日志，人工介入处理
            LOGGER.error("库存确认扣减失败，productId: {}, count: {}", 
                         inventoryDTO.getProductId(), inventoryDTO.getCount());
            return false;
        }
        return true;
    }
    
    /**
     * Cancel阶段：取消扣减（释放冻结库存）
     */
    public boolean cancel(InventoryDTO inventoryDTO) {
        LOGGER.info("======库存服务Cancel阶段：释放冻结库存======");
        
        // 释放冻结库存（lock_inventory -= count）
        int affected = inventoryMapper.cancelFreeze(inventoryDTO);
        
        // 空回滚防护：当affected=0时，说明Try阶段未执行，不做处理
        if (affected == 0) {
            LOGGER.warn("库存空回滚，productId: {}", inventoryDTO.getProductId());
            return true;
        }
        
        if (affected != 1) {
            LOGGER.error("库存取消失败，productId: {}, count: {}", 
                         inventoryDTO.getProductId(), inventoryDTO.getCount());
            return false;
        }
        return true;
    }
}

对应的MyBatis Mapper实现：

<!-- 预冻结库存 -->
<update id="freezeInventory">
    UPDATE inventory 
    SET lock_inventory = lock_inventory + #{count},
        update_time = NOW()
    WHERE product_id = #{productId}
      AND total_inventory >= #{count}
      AND lock_inventory + #{count} <= total_inventory
</update>

<!-- 确认扣减库存 -->
<update id="confirmDecrease">
    UPDATE inventory 
    SET total_inventory = total_inventory - #{count},
        lock_inventory = lock_inventory - #{count},
        update_time = NOW()
    WHERE product_id = #{productId}
      AND lock_inventory >= #{count}
</update>

<!-- 取消冻结库存 -->
<update id="cancelFreeze">
    UPDATE inventory 
    SET lock_inventory = lock_inventory - #{count},
        update_time = NOW()
    WHERE product_id = #{productId}
      AND lock_inventory >= #{count}
</update>

账户服务TCC实现

账户服务与库存服务实现类似，重点处理余额冻结与释放：

@Service
public class AccountServiceImpl implements AccountService {
    
    private static final Logger LOGGER = LoggerFactory.getLogger(AccountServiceImpl.class);
    
    private final AccountMapper accountMapper;
    
    @Autowired
    public AccountServiceImpl(AccountMapper accountMapper) {
        this.accountMapper = accountMapper;
    }
    
    /**
     * Try阶段：扣减余额（预冻结）
     */
    @Override
    @HmilyTCC(confirmMethod = "confirm", cancelMethod = "cancel")
    public boolean decrease(AccountDTO accountDTO) {
        LOGGER.info("======账户服务Try阶段：预冻结余额======");
        
        // 1. 检查余额是否充足
        AccountDO account = accountMapper.findByUserId(accountDTO.getUserId());
        if (account == null || account.getBalance().compareTo(accountDTO.getAmount()) < 0) {
            throw new HmilyRuntimeException("余额不足");
        }
        
        // 2. 预冻结余额
        int affected = accountMapper.freezeAmount(accountDTO);
        if (affected != 1) {
            throw new HmilyRuntimeException("余额冻结失败");
        }
        return true;
    }
    
    /**
     * Confirm阶段：确认扣减余额
     */
    public boolean confirm(AccountDTO accountDTO) {
        LOGGER.info("======账户服务Confirm阶段：确认扣减余额======");
        
        // 实际扣减余额（balance -= amount, freeze_amount -= amount）
        int affected = accountMapper.confirmDecrease(accountDTO);
        if (affected != 1) {
            LOGGER.error("余额确认扣减失败，userId: {}, amount: {}", 
                         accountDTO.getUserId(), accountDTO.getAmount());
            return false;
        }
        return true;
    }
    
    /**
     * Cancel阶段：取消扣减（释放冻结余额）
     */
    public boolean cancel(AccountDTO accountDTO) {
        LOGGER.info("======账户服务Cancel阶段：释放冻结余额======");
        
        // 释放冻结余额（freeze_amount -= amount）
        int affected = accountMapper.cancelFreeze(accountDTO);
        
        // 空回滚防护
        if (affected == 0) {
            LOGGER.warn("余额空回滚，userId: {}", accountDTO.getUserId());
            return true;
        }
        
        if (affected != 1) {
            LOGGER.error("余额取消失败，userId: {}, amount: {}", 
                         accountDTO.getUserId(), accountDTO.getAmount());
            return false;
        }
        return true;
    }
}

订单服务实现（事务发起者）

订单服务作为事务发起者，需要调用库存服务和账户服务，并协调整个事务：

@Service
public class OrderServiceImpl implements OrderService {
    
    private static final Logger LOGGER = LoggerFactory.getLogger(OrderServiceImpl.class);
    
    private final OrderMapper orderMapper;
    
    private final InventoryService inventoryService;
    
    private final AccountService accountService;
    
    @Autowired
    public OrderServiceImpl(OrderMapper orderMapper, 
                           @HmilyRemotingService InventoryService inventoryService,
                           @HmilyRemotingService AccountService accountService) {
        this.orderMapper = orderMapper;
        this.inventoryService = inventoryService;
        this.accountService = accountService;
    }
    
    /**
     * 创建订单，发起TCC事务
     */
    @Override
    @Transactional
    public String createOrder(OrderDTO orderDTO) {
        // 1. 本地事务：创建订单（状态：处理中）
        String orderNo = UUID.randomUUID().toString().replace("-", "");
        orderDTO.setOrderNo(orderNo);
        orderDTO.setStatus(0); // 0-处理中，1-成功，2-失败
        orderMapper.insert(orderDTO);
        
        try {
            // 2. 调用库存服务：扣减库存
            InventoryDTO inventoryDTO = new InventoryDTO();
            inventoryDTO.setProductId(orderDTO.getProductId());
            inventoryDTO.setCount(orderDTO.getCount());
            boolean inventoryResult = inventoryService.decrease(inventoryDTO);
            if (!inventoryResult) {
                throw new HmilyRuntimeException("库存扣减失败");
            }
            
            // 3. 调用账户服务：扣减余额
            AccountDTO accountDTO = new AccountDTO();
            accountDTO.setUserId(orderDTO.getUserId());
            accountDTO.setAmount(orderDTO.getAmount());
            boolean accountResult = accountService.decrease(accountDTO);
            if (!accountResult) {
                throw new HmilyRuntimeException("余额扣减失败");
            }
            
            // 4. 本地事务：更新订单状态为成功
            orderMapper.updateStatus(orderNo, 1);
            return orderNo;
        } catch (Exception e) {
            // 5. 异常处理：更新订单状态为失败
            orderMapper.updateStatus(orderNo, 2);
            LOGGER.error("创建订单失败", e);
            throw new HmilyRuntimeException("创建订单失败：" + e.getMessage());
        }
    }
}

注意事项：

1. 远程服务引用需添加@HmilyRemotingService注解，实现事务上下文传播
2. 事务发起者不需要@HmilyTCC注解，由框架自动识别
3. 本地事务使用@Transactional保证ACID特性
4. 异常处理中需更新订单状态，便于业务监控

异常处理与高级特性

典型异常场景测试

1. Try阶段异常

模拟库存服务Try阶段抛出异常：

@Override
@HmilyTCC(confirmMethod = "confirm", cancelMethod = "cancel")
public boolean decrease(InventoryDTO inventoryDTO) {
    LOGGER.info("======库存服务Try阶段：模拟异常======");
    throw new HmilyRuntimeException("库存扣减异常（模拟）");
}

预期结果：

• 库存服务Cancel方法执行，释放未冻结资源
• 账户服务未调用，无操作
• 订单状态更新为失败

2. Confirm阶段异常

模拟账户服务Confirm阶段抛出异常：

public boolean confirm(AccountDTO accountDTO) {
    LOGGER.info("======账户服务Confirm阶段：模拟异常======");
    throw new HmilyRuntimeException("余额确认异常（模拟）");
}

预期结果：

• Hmily框架会重试调用Confirm方法（默认3次）
• 重试失败后，事务状态标记为"待恢复"
• 后台Recovery任务会定时重试，直到成功或达到最大重试次数

3. 网络超时场景

模拟账户服务Try阶段超时：

@Override
@HmilyTCC(confirmMethod = "confirm", cancelMethod = "cancel")
public boolean decrease(AccountDTO accountDTO) {
    LOGGER.info("======账户服务Try阶段：模拟超时======");
    try {
        Thread.sleep(30000); // 休眠30秒，超过默认超时时间
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
    return accountMapper.freezeAmount(accountDTO) > 0;
}

预期结果：

• 调用方触发超时异常
• Hmily框架调用Cancel方法回滚
• 订单状态更新为失败

事务恢复机制

Hmily提供自动事务恢复机制，通过定时任务扫描异常事务并重试：

hmily:
  recover:
    enabled: true                # 启用恢复机制
    max-retry-count: 3           # 最大重试次数
    retry-delay: 5000            # 重试延迟(毫秒)
    scheduled-delay: 1000        # 定时任务间隔(毫秒)
    scheduled-thread-pool-size: 10 # 恢复线程池大小

恢复流程如下：

1. 定时扫描事务日志表，查找状态为"TRYING"且超时的事务
2. 调用对应服务的Cancel方法进行回滚
3. 对于状态为"CONFIRMING"/"CANCELING"的超时事务，重试执行
4. 超过最大重试次数的事务，标记为"FAIL"，需人工介入

监控与运维

Hmily提供丰富的监控指标和Admin管理后台，帮助开发者实时了解事务状态：

1. Metrics指标：

   • hmily_transaction_total：事务总数量
   • hmily_transaction_success：成功事务数量
   • hmily_transaction_fail：失败事务数量
   • hmily_transaction_recover：恢复事务数量

2. Admin管理后台：

   • 事务列表查询（按状态、时间等维度）
   • 异常事务手动恢复
   • 事务详情查看（包含参与方、执行日志）
   • 性能指标图表展示

性能优化实践

序列化优化

Hmily默认使用hessian序列化，可替换为kryo提升性能：

hmily:
  service:
    serializer: kryo # 可选：kryo, hessian, protostuff

测试表明，kryo序列化相比hessian可提升约40%的吞吐量。

日志存储优化

根据业务场景选择合适的日志存储方案：

存储方案	优势	劣势	适用场景
MySQL	可靠性高，支持事务	性能一般，需分表	中小规模应用
Redis	性能优异，低延迟	可能丢失数据	高并发非核心业务
MongoDB	文档存储，易扩展	事务支持弱	大数据量场景

高并发场景建议使用Redis+MySQL双写方案，兼顾性能与可靠性。

异步日志写入

启用异步日志写入可显著提升性能：

hmily:
  repository:
    database:
      async: true # 异步写入事务日志
      queue-capacity: 10240 # 队列容量
      thread-num: 8 # 异步线程数

异步写入可将事务吞吐量提升2-3倍，但需注意：

• 应用停机时可能丢失未写入的日志
• 需监控队列堆积情况，避免OOM

批量处理优化

对于高频小事务，可采用批量处理优化：

@HmilyTCC(confirmMethod = "confirmBatch", cancelMethod = "cancelBatch")
public boolean batchDecrease(List<InventoryDTO> list) {
    // 批量预冻结库存
    return inventoryMapper.batchFreeze(list) > 0;
}

public boolean confirmBatch(List<InventoryDTO> list) {
    // 批量确认扣减
    return inventoryMapper.batchConfirm(list) > 0;
}

批量处理可减少RPC调用次数和日志写入次数，提升吞吐量。

生产环境部署与运维

集群部署架构

Hmily采用去中心化设计，天然支持集群部署：

部署注意事项：

1. 所有服务节点必须使用相同的配置（序列化方式、日志存储等）
2. 事务日志存储必须使用集群模式，保证高可用
3. 建议使用配置中心（如Nacos/Apollo）统一管理配置

事务监控告警

关键监控指标与告警阈值建议：

指标	告警阈值	处理建议
失败事务率	>0.1%	检查服务健康状态
事务平均耗时	>500ms	优化业务逻辑，减少锁等待
恢复任务积压	>1000	增加恢复线程数，检查网络
日志写入延迟	>100ms	优化存储性能，考虑异步写入

可通过Prometheus+Grafana搭建监控平台，配置告警规则：

groups:
- name: hmily_alerts
  rules:
  - alert: TransactionFailureRate
    expr: sum(rate(hmily_transaction_fail[5m])) / sum(rate(hmily_transaction_total[5m])) > 0.001
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "事务失败率过高"
      description: "失败率: {{ $value | humanizePercentage }}"

常见问题排查

1. 事务日志表数据膨胀

解决方案：

• 定期归档历史数据（如超过30天的成功事务）
• 使用分表策略（按时间或事务ID哈希）
• 配置日志自动清理：

hmily:
  repository:
    database:
      clean:
        enabled: true
        retain-days: 30 # 保留30天日志

2. 分布式事务死锁

排查步骤：

1. 查看数据库死锁日志（show engine innodb status）
2. 检查TCC方法是否持有长事务锁
3. 优化SQL，减少锁等待时间
4. 调整事务隔离级别（建议使用READ COMMITTED）

3. 事务恢复任务效率低

优化方案：

1. 增加恢复线程数
2. 按事务ID分片处理，避免单表热点
3. 针对特定异常类型优化重试策略
4. 非核心事务降低重试优先级

总结与展望

本文详细介绍了Hmily TCC模式的实现原理和实践指南，从环境搭建、代码实现到性能优化、生产部署，全方位覆盖了分布式事务开发的关键环节。通过Hmily框架，我们可以轻松实现金融级的分布式事务解决方案，解决微服务架构中的数据一致性难题。

Hmily目前已支持TCC和TAC两种模式，未来还将引入SAGA模式，提供更全面的事务解决方案。同时，社区正在开发多语言SDK和Serverless架构支持，进一步扩展应用场景。

分布式事务领域仍在快速发展，Hmily作为开源解决方案，欢迎各位开发者参与贡献，共同打造更稳定、更高效的分布式事务框架。

行动指南：

1. 克隆Hmily源码，运行demo示例，体验TCC模式
2. 在测试环境中集成Hmily，验证业务场景
3. 关注Dromara社区，获取最新版本和最佳实践
4. 参与Hmily社区讨论，分享你的使用经验

【免费下载链接】hmily 金融级分布式事务解决方案 项目地址: https://gitcode.com/dromara/hmily