Apache Seata TCC模式下RR隔离级别导致的死锁问题分析

问题背景

在分布式事务处理框架Apache Seata的TCC模式下，当启用useTCCFence功能且MySQL事务隔离级别设置为REPEATABLE READ(RR)时，可能会遇到一个特殊场景下的死锁问题。这种情况发生在prepare阶段和rollback阶段都出现悬挂现象时，多个rollback请求并发执行会导致MySQL报告"Deadlock found when trying to get lock"错误。

技术原理分析

TCC模式与Fence机制

Seata的TCC模式通过Try-Confirm-Cancel三个阶段实现分布式事务。useTCCFence功能引入了一个防悬挂机制，通过在数据库中维护tcc_fence_log表来记录事务状态，防止重复提交或回滚。

RR隔离级别下的锁机制

在MySQL的REPEATABLE READ隔离级别下，当执行SELECT...FOR UPDATE查询时，如果目标记录不存在，查询会退化为间隙锁(Gap Lock)。多个事务可以同时获取相同范围的间隙锁，但当这些事务尝试插入该间隙范围内的记录时，就会互相等待对方的锁释放，从而导致死锁。

问题发生场景

1. prepare阶段发生悬挂，导致tcc_fence_log表中没有对应记录
2. rollback阶段也发生悬挂，触发重试机制
3. 多个rollback请求并发执行，每个都开启独立事务
4. 每个事务先执行SELECT...FOR UPDATE查询，由于记录不存在，获取间隙锁
5. 接着执行INSERT操作，需要等待其他事务释放间隙锁
6. 形成循环等待，MySQL检测到死锁

解决方案对比

方案1：调整SQL执行顺序

将SELECT...FOR UPDATE和INSERT操作顺序调换。先尝试INSERT，遇到重复键异常再执行SELECT...FOR UPDATE。这种方案虽然能避免死锁，但会增加正常情况下的SQL执行次数，影响性能。

方案2：引入分布式锁

使用Redis等中间件实现分布式锁，控制prepareFence、commitFence和rollbackFence操作的并发。这种方案能解决问题，但引入了额外的网络IO开销，增加了系统复杂度。

方案3：临时调整隔离级别

在执行fence操作时，临时将事务隔离级别降为READ COMMITTED(RC)。RC级别下没有间隙锁，可以避免死锁，同时保持原有业务逻辑不变。这种方案实现简单，对性能影响小。

方案4：可配置隔离级别

在TCCFence配置中增加隔离级别参数，允许用户根据实际情况选择合适的事务隔离级别。这种方案提供了最大的灵活性，但需要用户具备相关知识来正确配置。

推荐解决方案

综合考量实现复杂度、性能影响和易用性，推荐采用方案3或方案4：

1. 方案3适合大多数场景，通过临时降低隔离级别来避免死锁，无需用户额外配置
2. 方案4适合需要精细控制的场景，为用户提供配置选项

两种方案都能将错误从死锁转变为重复键异常，后者更容易被系统处理，不会导致事务完全失败，而是触发重试机制。

实现细节

在Spring环境中，可以通过TransactionTemplate来动态设置隔离级别：

// 方案3实现示例
transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
try {
    // 执行fence操作
} finally {
    transactionTemplate.setIsolationLevel(originalLevel);
}

对于方案4，需要在配置类中添加隔离级别参数：

@ConfigurationProperties(prefix = "seata.tcc.fence")
public class TCCFenceConfig {
    private int isolationLevel = TransactionDefinition.ISOLATION_DEFAULT;
    // getter/setter
}

总结

Apache Seata在TCC模式下使用RR隔离级别时可能出现的死锁问题，本质上是由于MySQL的间隙锁机制与Seata的重试机制共同作用导致的。通过合理调整事务隔离级别，可以在不显著影响性能的前提下有效解决这一问题。开发者应根据实际场景选择合适的解决方案，确保分布式事务的可靠性和系统稳定性。