SpringBoot + 分布式锁 + 事务日志：跨服务操作原子性兜底方案

小马爱打代码2026-06-03 8:20

01 跨服务操作的那些坑，你踩过几个？

你是否遇到过这样的场景：用户在 APP 上兑换一张价值 1000 积分的优惠券，系统扣减了用户积分，可优惠券却没能成功发放。

用户投诉到客服，客服排查半天后发现，是流程中某个服务调用失败，导致整个兑换流程中断。

更棘手的是，跨服务操作引发的数据不一致问题，定位和修复起来难度极大，最后只能人工给用户补发优惠券。

作为后端开发者，这样的场景是不是让你感同身受？

02 为什么跨服务操作这么难？

在微服务架构体系下，一个完整的业务流程往往需要多个独立服务协同完成，比如：

  • 订单服务：负责创建订单
  • 库存服务：负责扣减库存
  • 支付服务：负责处理支付
  • 物流服务：负责安排发货

每个服务都是独立部署的，且拥有专属的数据库。

当业务流程需要跨多个服务执行时，原子性就成了核心难题。

什么是原子性？ 简单来说，就是一个操作"要么全部执行成功，要么全部不执行"。

在单体应用中，我们可以借助数据库事务轻松保证原子性；但在微服务架构下，分布式事务的实现复杂度呈指数级上升。

03 分布式事务的困境

提到分布式事务，大家大概率会想到这些主流方案：

  • 2PC（两阶段提交）：性能表现差，极易出现阻塞问题
  • TCC（Try-Confirm-Cancel）：实现逻辑复杂，对业务代码有强侵入性
  • Saga：适用于长事务场景，但状态管理难度高
  • 本地消息表：依赖消息队列实现，存在较高的延迟问题

这些方案各有优劣，但在实际项目落地中，我们往往需要一套更简洁、更可靠的兜底方案。

04 兜底方案：SpringBoot + 分布式锁 + 事务日志

今天要和大家分享的，是经过实战验证的跨服务原子性解决方案：SpringBoot + 分布式锁 + 事务日志。

这套方案的核心逻辑是：通过分布式锁解决并发问题，通过事务日志记录操作全流程，再通过补偿机制兜底异常场景，最终实现跨服务操作的最终一致性。

05 方案详解

5.1 分布式锁：解决并发问题

跨服务操作中，并发请求是引发数据不一致的重要诱因。

如果多个请求同时处理同一个业务流程，很容易导致数据错乱。

我们可以基于 Redis 实现分布式锁，保证同一业务流程同一时间只有一个请求在执行：

java 复制代码 
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import java.util.Collections;
import java.util.concurrent.TimeUnit;

/**
 * Redis分布式锁实现类
 * 核心功能：加锁（非阻塞）、解锁（防止误删）
 */
public class RedisDistributedLock {

    // 注入Redis操作模板
    private RedisTemplate<String, String> redisTemplate;

    /**
     * 尝试获取分布式锁
     * @param key 锁的唯一标识（如：业务+用户ID）
     * @param value 锁的唯一值（UUID），用于防止误解锁
     * @param expireTime 锁的过期时间（秒），防止死锁
     * @return 获取锁成功返回true，失败返回false
     */
    public boolean tryLock(String key, String value, long expireTime) {
        // setIfAbsent：Redis的NX指令，只有key不存在时才设置值，保证原子性
        return redisTemplate.opsForValue()
            .setIfAbsent(key, value, expireTime, TimeUnit.SECONDS);
    }

    /**
     * 释放分布式锁
     * @param key 锁的唯一标识
     * @param value 锁的唯一值
     * @return 解锁成功返回true，失败返回false
     */
    public boolean unlock(String key, String value) {
        // Lua脚本：保证"查值+删值"原子性，防止删除其他线程持有的锁
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 执行Lua脚本
        Object result = redisTemplate.execute(
            new DefaultRedisScript<>(script, Long.class),
            Collections.singletonList(key), 
            value
        );
        // 结果为1表示解锁成功
        return result != null && Long.valueOf(1).equals(result);
    }

    // 构造方法注入RedisTemplate
    public RedisDistributedLock(RedisTemplate<String, String> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }
}

在执行跨服务操作前，先获取分布式锁，确保操作的排他性：

java 复制代码 
import java.util.UUID;

/**
 * 积分兑换优惠券服务
 * 核心功能：处理用户积分兑换优惠券的跨服务操作
 */
public class ExchangeService {

    // 注入分布式锁工具类
    private RedisDistributedLock distributedLock;

    /**
     * 积分兑换优惠券主方法
     * @param userId 用户ID
     * @param couponId 优惠券ID
     * @param points 兑换所需积分
     */
    public void exchangeCoupon(String userId, String couponId, int points) {
        // 构造锁的key：保证同一用户+同一优惠券的操作互斥
        String lockKey = "exchange:lock:" + userId + ":" + couponId;
        // 生成唯一的锁value：防止解锁时误删其他线程的锁
        String lockValue = UUID.randomUUID().toString();

        try {
            // 尝试获取锁，过期时间30秒（根据业务调整）
            boolean locked = distributedLock.tryLock(lockKey, lockValue, 30);
            if (!locked) {
                throw new RuntimeException("操作过于频繁，请稍后重试");
            }

            // 获取锁成功，执行核心兑换逻辑
            doExchange(userId, couponId, points);

        } finally {
            // 最终释放锁：无论操作成功/失败，都要释放锁，避免死锁
            distributedLock.unlock(lockKey, lockValue);
        }
    }

    // 核心兑换逻辑（后续实现）
    private void doExchange(String userId, String couponId, int points) {
        // 扣减积分、发放优惠券等跨服务操作
    }

    // 构造方法注入分布式锁
    public ExchangeService(RedisDistributedLock distributedLock) {
        this.distributedLock = distributedLock;
    }
}

5.2 事务日志：记录操作全流程

事务日志是整个方案的核心，它会记录跨服务操作的每一步详情，为后续的补偿机制提供数据依据。

首先创建事务日志表：

sql 复制代码 
-- 事务日志表：记录跨服务操作的全生命周期
CREATE TABLE `transaction_log` (
  `id` BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '自增主键',
  `transaction_id` VARCHAR(64) NOT NULL COMMENT '全局唯一事务ID',
  `business_type` VARCHAR(32) NOT NULL COMMENT '业务类型（如：EXCHANGE_COUPON-积分兑换优惠券）',
  `business_id` VARCHAR(64) NOT NULL COMMENT '业务ID（如：用户ID）',
  `status` VARCHAR(16) NOT NULL COMMENT '事务状态：PENDING-待执行/COMPLETED-已完成/FAILED-执行失败',
  `content` JSON NOT NULL COMMENT '操作内容（JSON格式，存储业务参数）',
  `retry_count` INT DEFAULT 0 COMMENT '补偿重试次数',
  `create_time` DATETIME NOT NULL COMMENT '创建时间',
  `update_time` DATETIME NOT NULL COMMENT '更新时间',
  UNIQUE KEY `uk_transaction_id` (`transaction_id`) COMMENT '事务ID唯一索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='跨服务操作事务日志表';

然后实现事务日志的核心操作服务：

java 复制代码 
import com.alibaba.fastjson.JSON;
import org.springframework.stereotype.Service;
import java.time.LocalDateTime;
import java.util.List;
import java.util.UUID;

/**
 * 事务日志服务
 * 核心功能：创建日志、更新状态、查询待补偿日志
 */
@Service
public class TransactionLogService {

    // 注入事务日志仓储层（MyBatis/JPA等）
    private TransactionLogRepository logRepository;

    /**
     * 创建事务日志
     * @param businessType 业务类型
     * @param businessId 业务ID
     * @param content 业务参数（任意对象，自动转为JSON）
     * @return 保存后的事务日志对象
     */
    public TransactionLog createLog(String businessType, String businessId, Object content) {
        // 生成全局唯一事务ID
        String transactionId = UUID.randomUUID().toString();
        TransactionLog log = new TransactionLog();
        
        log.setTransactionId(transactionId);
        log.setBusinessType(businessType);
        log.setBusinessId(businessId);
        log.setStatus(TransactionStatus.PENDING); // 初始状态：待执行
        log.setContent(JSON.toJSONString(content)); // 业务参数转为JSON
        log.setRetryCount(0); // 初始重试次数：0
        log.setCreateTime(LocalDateTime.now());
        log.setUpdateTime(LocalDateTime.now());
        
        // 保存日志到数据库
        return logRepository.save(log);
    }

    /**
     * 更新事务状态
     * @param transactionId 事务ID
     * @param status 新状态（COMPLETED/FAILED）
     */
    public void updateStatus(String transactionId, TransactionStatus status) {
        TransactionLog log = logRepository.findByTransactionId(transactionId);
        if (log != null) {
            log.setStatus(status);
            log.setUpdateTime(LocalDateTime.now());
            logRepository.save(log);
        }
    }

    /**
     * 查询待补偿的事务日志
     * @param maxRetryCount 最大重试次数（防止无限重试）
     * @return 待补偿的日志列表
     */
    public List<TransactionLog> getPendingLogs(int maxRetryCount) {
        // 查询状态为PENDING且重试次数小于maxRetryCount的日志
        return logRepository.findByStatusAndRetryCountLessThan(
            TransactionStatus.PENDING, 
            maxRetryCount
        );
    }

    // 构造方法注入仓储层
    public TransactionLogService(TransactionLogRepository logRepository) {
        this.logRepository = logRepository;
    }
}

// 事务状态枚举（单独定义）
enum TransactionStatus {
    PENDING,   // 待执行
    COMPLETED, // 已完成
    FAILED     // 执行失败
}

// 事务日志实体类（简化版）
class TransactionLog {
    private Long id;
    private String transactionId;
    private String businessType;
    private String businessId;
    private TransactionStatus status;
    private String content;
    private Integer retryCount;
    private LocalDateTime createTime;
    private LocalDateTime updateTime;

    // 省略getter/setter
}

// 事务日志仓储层接口（简化版）
interface TransactionLogRepository {
    TransactionLog save(TransactionLog log);
    TransactionLog findByTransactionId(String transactionId);
    List<TransactionLog> findByStatusAndRetryCountLessThan(TransactionStatus status, int maxRetryCount);
}

5.3 补偿机制：兜底失败场景

即便做好了前置准备，跨服务操作仍可能因网络、服务异常等原因失败。

此时，补偿机制就能发挥作用，通过重试失败的操作，保证业务最终一致性：

java 复制代码 
import com.alibaba.fastjson.JSON;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import java.util.List;

/**
 * 补偿任务（定时执行）
 * 核心功能：扫描待补偿日志，重试失败的跨服务操作
 */
@Component
public class CompensationTask {

    private static final Logger log = LoggerFactory.getLogger(CompensationTask.class);

    // 注入事务日志服务
    private TransactionLogService logService;
    // 注入兑换业务服务
    private ExchangeService exchangeService;

    /**
     * 执行补偿逻辑（建议配置为定时任务，如每5分钟执行一次）
     */
    @Scheduled(fixedRate = 300000) // 5分钟执行一次，单位：毫秒
    public void executeCompensation() {
        log.info("开始执行跨服务操作补偿任务");

        try {
            // 查询待补偿的日志（最大重试3次，避免无限重试）
            List<TransactionLog> pendingLogs = logService.getPendingLogs(3);

            for (TransactionLog log : pendingLogs) {
                try {
                    // 只处理积分兑换优惠券的业务
                    if ("EXCHANGE_COUPON".equals(log.getBusinessType())) {
                        // 解析日志中的业务参数
                        ExchangeContent content = JSON.parseObject(
                            log.getContent(), 
                            ExchangeContent.class
                        );

                        // 重试核心兑换逻辑
                        exchangeService.doExchange(
                            content.getUserId(),
                            content.getCouponId(),
                            content.getPoints()
                        );

                        // 重试成功，更新日志状态为已完成
                        logService.updateStatus(log.getTransactionId(), TransactionStatus.COMPLETED);
                        log.info("补偿任务执行成功，事务ID：{}", log.getTransactionId());
                    }
                } catch (Exception e) {
                    log.error("补偿任务执行失败，事务ID：{}", log.getTransactionId(), e);
                    // 重试失败，增加重试次数
                    log.setRetryCount(log.getRetryCount() + 1);
                    logService.save(log);
                }
            }
        } catch (Exception e) {
            log.error("补偿任务整体执行异常", e);
        }

        log.info("跨服务操作补偿任务执行完成");
    }

    // 构造方法注入依赖
    public CompensationTask(TransactionLogService logService, ExchangeService exchangeService) {
        this.logService = logService;
        this.exchangeService = exchangeService;
    }

    // 兑换业务参数实体
    static class ExchangeContent {
        private String userId;
        private String couponId;
        private int points;

        // 省略getter/setter
    }
}

5.4 核心业务整合：将锁、日志、补偿串联

最后，把分布式锁、事务日志、补偿机制整合到核心业务中：

java 复制代码 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * 积分兑换优惠券核心服务（完整版）
 * 整合分布式锁、事务日志、跨服务调用
 */
public class ExchangeService {

    private static final Logger log = LoggerFactory.getLogger(ExchangeService.class);

    // 注入分布式锁
    private RedisDistributedLock distributedLock;
    // 注入事务日志服务
    private TransactionLogService logService;
    // 注入积分服务
    private PointsService pointsService;
    // 注入优惠券服务
    private CouponService couponService;

    /**
     * 积分兑换优惠券入口方法
     * @param userId 用户ID
     * @param couponId 优惠券ID
     * @param points 兑换所需积分
     */
    public void exchangeCoupon(String userId, String couponId, int points) {
        String lockKey = "exchange:lock:" + userId + ":" + couponId;
        String lockValue = UUID.randomUUID().toString();
        String transactionId = null;

        try {
            // 1. 获取分布式锁
            boolean locked = distributedLock.tryLock(lockKey, lockValue, 30);
            if (!locked) {
                throw new RuntimeException("操作过于频繁，请稍后重试");
            }

            // 2. 执行核心兑换逻辑（包含日志记录）
            transactionId = doExchange(userId, couponId, points);

        } catch (Exception e) {
            log.error("积分兑换优惠券失败，用户ID：{}，优惠券ID：{}", userId, couponId, e);
            // 3. 操作失败，更新日志状态为FAILED
            if (transactionId != null) {
                logService.updateStatus(transactionId, TransactionStatus.FAILED);
            }
            throw e; // 抛出异常，让上层感知
        } finally {
            // 4. 释放分布式锁
            distributedLock.unlock(lockKey, lockValue);
        }
    }

    /**
     * 核心兑换逻辑（包含事务日志记录）
     * @param userId 用户ID
     * @param couponId 优惠券ID
     * @param points 兑换所需积分
     * @return 事务ID
     */
    public String doExchange(String userId, String couponId, int points) {
        // 封装业务参数
        CompensationTask.ExchangeContent content = new CompensationTask.ExchangeContent();
        content.setUserId(userId);
        content.setCouponId(couponId);
        content.setPoints(points);

        // 1. 创建事务日志（初始状态：PENDING）
        TransactionLog log = logService.createLog("EXCHANGE_COUPON", userId, content);
        String transactionId = log.getTransactionId();

        try {
            // 2. 扣减用户积分（跨服务调用）
            pointsService.deductPoints(userId, points);

            // 3. 发放优惠券（跨服务调用）
            couponService.grantCoupon(userId, couponId);

            // 4. 操作全部成功，更新日志状态为COMPLETED
            logService.updateStatus(transactionId, TransactionStatus.COMPLETED);

            return transactionId;
        } catch (Exception e) {
            // 5. 操作失败，抛出异常（外层会更新日志状态）
            throw new RuntimeException("核心兑换逻辑执行失败", e);
        }
    }

    // 构造方法注入所有依赖
    public ExchangeService(RedisDistributedLock distributedLock, TransactionLogService logService, PointsService pointsService, CouponService couponService) {
        this.distributedLock = distributedLock;
        this.logService = logService;
        this.pointsService = pointsService;
        this.couponService = couponService;
    }

    // 积分服务接口（简化）
    interface PointsService {
        void deductPoints(String userId, int points);
    }

    // 优惠券服务接口（简化）
    interface CouponService {
        void grantCoupon(String userId, String couponId);
    }
}

06 方案优势

  • 实现简单：无需引入复杂的分布式事务框架，基于 Redis 和数据库即可落地，学习成本低，团队上手快。
  • 可靠性高：通过分布式锁保证并发安全，通过事务日志记录操作全流程，通过补偿机制兜底异常场景，形成完整闭环。
  • 扩展性强：方案核心组件（锁、日志、补偿）均可独立扩展，可根据业务需求灵活调整。
  • 性能可控：相比 2PC、TCC 等方案，本方案对业务性能影响小，补偿任务可异步执行，不影响主流程响应时间。
  • 监控友好：事务日志表天然提供了操作追踪和监控能力，便于排查问题和分析业务数据。

07 适用场景与注意事项

7.1 适用场景

  1. 积分兑换优惠券：如本文示例，扣减积分和发放优惠券需要保证原子性。
  2. 订单创建与库存扣减：创建订单后需要同步扣减库存，避免超卖。
  3. 用户注册与初始化：注册成功后需要初始化用户资料、发送欢迎消息等。
  4. 跨服务状态同步：如用户等级变更后，需要同步更新多个服务的缓存。

7.2 注意事项

  1. 锁的粒度要合理：锁的 key 设计要兼顾并发安全和性能，避免锁粒度过大导致性能瓶颈。
  2. 补偿任务幂等性：补偿逻辑必须保证幂等，防止重复执行导致数据错乱。
  3. 日志清理策略：事务日志表会持续增长，需要制定合理的清理策略（如保留 30 天）。
  4. 监控告警：需要监控补偿任务的执行情况，对连续失败的任务及时告警。
  5. 网络超时设置：跨服务调用需要设置合理的超时时间，避免长时间阻塞。

08 总结

跨服务操作的原子性保障是微服务架构下的核心挑战之一。本文介绍的 SpringBoot + 分布式锁 + 事务日志 方案，通过以下三个核心组件实现了最终一致性：

  1. 分布式锁：解决并发请求导致的数据不一致问题。
  2. 事务日志：记录操作全流程，为补偿提供数据依据。
  3. 补偿机制：定时重试失败操作，保证业务最终一致性。

这套方案已在多个生产环境中验证，具有实现简单、可靠性高、扩展性强等优点。虽然它不能替代分布式事务框架的所有场景，但对于大多数业务场景来说，是一个实用且可靠的兜底方案。

希望本文能为你解决跨服务操作的数据一致性问题提供有价值的参考。在实际应用中，可以根据具体业务需求对方案进行定制和优化。

相关推荐
数据库小学妹1 小时前
分布式数据库选型实战：Share-Nothing、Share-Disk、Share-Storage三种架构对比
数据库·经验分享·分布式·架构·dba
Rust研习社1 小时前
从 LaunchBadge 到 transact-rs：SQLx 社区迈出可持续治理的第一步
开发语言·后端·rust
真实的菜1 小时前
Spring Boot 2.2.x 优雅停机实践指南
spring boot·后端
宸津-代码粉碎机1 小时前
Spring AI企业级RAG进阶｜文档智能分片调优、ES深度整合、接口限流熔断监控生产实战
java·开发语言·人工智能·后端·spring·elasticsearch·oracle
JustHappy10 小时前
古法编程秘籍（二）：什么是代码模块化？别背概念，把房间收拾明白就够了
前端·后端
小江的记录本11 小时前
【JVM虚拟机】堆内存分代模型：年轻代（Eden+Survivor）、老年代、元空间Metaspace（附《思维导图》+《面试高频考点清单》）
java·前端·jvm·后端·python·spring·面试
逍遥德12 小时前
MQTT教程详解-04.SpringBoot集成MQTT(告别手动控制)
java·spring boot·物联网·中间件·iot·iotdb
IT_陈寒14 小时前
Python闭包里藏的这个坑，差点让我加班到凌晨
前端·人工智能·后端
IT_陈寒14 小时前
Java注解空指针？这个坑我踩得莫名其妙
前端·人工智能·后端
热门推荐
01GitHub 镜像站点022026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf03【AI】2026 年具身智能模型和世界模型总结04Codex 下载安装指南：Windows 和 macOS 官方版下载05【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07CC-Switch 下载、安装与使用配置指南【2026.5.29】08CC-Switch & Claude 基于 Linux 服务器安装使用指南09Codex 接入 DeepSeek API 完整配置文档10几个好用的ip纯净度检测网站