Redisson + 编程式事务：分布式锁与原子性操作实践

一、背景介绍

在微服务架构中，当业务场景涉及唯一性约束或强事务一致性时，通常需要借助“分布式锁 + 事务机制”来确保数据操作的正确性与原子性。
然而，在日常开发中，分布式锁与事务的逻辑往往被反复编写，既增加了代码冗余，也使业务代码显得复杂、难以维护。为此，我们可以通过抽象与封装的方式，将分布式锁与编程式事务结合，构建一个通用的工具类，以简化开发、提升代码质量。

二、解决方案

本方案采用“分布式锁 + 编程式事务”的设计思路，通过封装通用模板逻辑，为开发者提供对事务性方法与非事务性方法的统一支持。
相比传统的声明式事务方式，该方案能够有效减少样板代码，无需显式处理分布式锁的获取与释放逻辑，也不必关心嵌套事务、事务传播行为等复杂细节。
开发者只需专注于业务逻辑本身，即可在保证数据一致性的前提下，实现更加简洁、可复用、可维护的代码结构。

目前的分布式锁工具类，还会有以下的注意事项，在使用时需要进行考虑的点：

1. 锁范围与性能优化（LRA原则）
优化目标： 最大化锁外逻辑，最小化锁内代码。

前置校验： 所有不涉及 DB 查询的参数校验（可使用 jakarta.validation.constraints进行部分参数校验，涉及DB查询校验的参数，需要考虑是否需要放于事物内进行），必须放在分布式锁代码块外部。

耗时操作： 不会因事务可见性产生问题的高耗时操作（如长时间 I/O、复杂的内存计算）应移至锁外执行。

2. 锁超时机制的权衡（禁用看门狗）
当前策略： 显式指定较长的锁持有时间（leaseTime），禁用 Redisson 看门狗自动续期机制。

优点： 避免了看门狗续期带来的网络开销和潜在的性能抖动。

风险与考量：

锁死风险： 若业务执行时间超过 leaseTime，或应用遭遇 OOM/硬崩溃导致未正常释放锁，可能引发 “锁死” 问题。

leaseTime 设定： 必须确保 leaseTime 远大于业务执行的最长耗时。

3. 事务隔离级别
默认配置： 编程式事务固定使用 “读已提交” (TransactionDefinition.ISOLATION_READ_COMMITTED) 隔离级别。

灵活性： 该配置满足当前业务需求，如有特殊要求，调用方需自行考虑扩展或调整事务定义。

@Service
@Slf4j
@RequiredArgsConstructor
public class RedisLockTool {

    private final RedissonClient redissonClient;

    private final PlatformTransactionManager txManager;
    //有r