首页 后端 技术文章

# 引言

核心价值：帮你彻底搞懂并发场景下的数据一致性问题，掌握事务隔离级别和传播机制的实战应用。读完本文，你将能够：识别并发退款场景的 5 种数据错乱问题、选择合适的事务隔离级别、设计防重复提交机制、避免 "超卖"、"重复退款" 等生产事故。

业务痛点：在我们电商平台的退款系统中，技术团队发现一个严重问题：用户快速点击退款按钮时，竟然能成功退款两次！更离谱的是，并发退款时出现了 "退款金额大于订单金额" 的诡异情况。财务对账时发现账目不平，导致整个财务系统停摆一天，损失惨重。

阅读前提：了解 Spring 事务管理的基本用法，知道什么是数据库事务，熟悉 MySQL 的基础操作，理解并发编程的基本概念。

# 核心原理：并发退款为什么容易出问题？

并发退款本质上就是多个线程同时操作同一笔订单的退款数据。这就像多个人同时从同一个银行账户取钱，如果没有合适的控制机制，就会出现各种问题。

类比理解：把并发退款想象成 "多人同时操作一个共享账本"。如果每个人都直接在账本上写 "退款 100 元"，没有任何协调机制，最终账本上的记录就会混乱不堪。可能一个人退款了两次，或者退款金额超过了原始金额。

技术本质：并发退款面临的核心问题是：

  • 竞态条件：多个线程同时读取和修改同一数据
  • 幻读问题：一个事务在执行过程中，另一个事务插入了新数据
  • 脏读问题：读取到未提交的数据
  • 不可重复读：同一事务中多次读取同一数据得到不同结果

# 实践方案：从问题复现到完整解决方案

# 场景约束

适合所有涉及资金操作、库存管理、积分变更等需要强一致性的场景。不适合对一致性要求不高、允许最终一致的业务场景（如社交点赞、浏览量统计等）。

# 问题复现：最小可复现代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
@RestController
public class RefundController {
    
    @Autowired
    private RefundService refundService;
    
    /**
     * 有问题的退款接口
     * 问题：没有并发控制，可能导致重复退款
     */
    @PostMapping("/refunds")
    public String processRefund(@RequestBody RefundRequest request) {
        // 直接处理退款，没有任何并发控制
        boolean success = refundService.processRefund(
            request.getOrderId(), 
            request.getAmount()
        );
        
        return success ? "退款成功" : "退款失败";
    }
}

@Service
public class RefundService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private RefundRepository refundRepository;
    
    /**
     * 有问题的退款处理逻辑
     * 问题：没有事务隔离，存在并发安全问题
     */
    @Transactional
    public boolean processRefund(Long orderId, BigDecimal amount) {
        // 步骤1：查询订单信息
        Order order = orderRepository.findById(orderId).orElse(null);
        if (order == null) {
            return false;
        }
        
        // 步骤2：检查是否可以退款
        if (order.getRefundedAmount().add(amount).compareTo(order.getTotalAmount()) > 0) {
            return false; // 退款金额超过订单金额
        }
        
        // 步骤3：更新订单退款金额
        order.setRefundedAmount(order.getRefundedAmount().add(amount));
        orderRepository.save(order);
        
        // 步骤4：创建退款记录
        Refund refund = new Refund();
        refund.setOrderId(orderId);
        refund.setAmount(amount);
        refund.setStatus("SUCCESS");
        refundRepository.save(refund);
        
        return true;
    }
}

代码分析：这段代码的问题在于 "假设单线程执行"。在并发场景下，两个线程可能同时执行到步骤 2，都发现可以退款，然后都执行步骤 3 和步骤 4，导致重复退款。就像两个人同时查看银行账户余额，都看到有 1000 元，然后同时取款 500 元，结果账户被取走了 1000 元。

# 并发问题：从重复退款到数据错乱

问题一：重复退款

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// 测试代码：模拟并发重复退款
@Test
public void testConcurrentRefund() throws InterruptedException {
    Long orderId = 12345L;
    BigDecimal refundAmount = new BigDecimal("100");
    
    // 创建10个线程同时退款
    ExecutorService executor = Executors.newFixedThreadPool(10);
    CountDownLatch latch = new CountDownLatch(10);
    AtomicInteger successCount = new AtomicInteger(0);
    
    for (int i = 0; i < 10; i++) {
        executor.submit(() -> {
            try {
                boolean success = refundService.processRefund(orderId, refundAmount);
                if (success) {
                    successCount.incrementAndGet();
                }
            } finally {
                latch.countDown();
            }
        });
    }
    
    latch.await();
    
    // 检查结果：可能多个退款都成功了
    Order order = orderRepository.findById(orderId).orElse(null);
    System.out.println("成功退款次数: " + successCount.get());
    System.out.println("订单退款金额: " + order.getRefundedAmount());
    
    // 问题：退款次数可能 > 1，退款金额可能 > 订单金额
}

问题二：超量退款

1
2
// 问题场景：订单金额1000元，并发退款600元两次
// 结果：实际退款1200元，超过订单金额

问题三：数据不一致

1
2
// 问题场景：退款记录创建了，但订单退款金额没有更新
// 结果：财务对账时发现账目不平

真实案例：我们线上退款系统在一次促销活动中，由于并发问题导致同一笔订单被退款了 3 次，总退款金额达到订单金额的 300%。财务对账时发现了这个问题，不得不人工回滚资金，影响了上千个用户。

# 解决方案：多层次的并发控制

# 第一层：数据库层面的乐观锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * 订单实体类 - 添加版本号字段
 */
@Entity
@Table(name = "orders")
public class Order {
    
    @Id
    private Long id;
    
    private BigDecimal totalAmount;
    
    private BigDecimal refundedAmount;
    
    /**
     * 乐观锁版本号
     */
    @Version
    private Long version;
    
    // getter/setter省略
}

/**
 * 使用乐观锁的退款服务
 */
@Service
public class OptimisticRefundService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private RefundRepository refundRepository;
    
    /**
     * 基于乐观锁的退款处理
     */
    @Transactional(rollbackFor = Exception.class)
    public boolean processRefundWithOptimisticLock(Long orderId, BigDecimal amount) {
        while (true) {
            // 查询订单（包含版本号）
            Order order = orderRepository.findById(orderId).orElse(null);
            if (order == null) {
                return false;
            }
            
            // 检查退款金额是否合法
            if (order.getRefundedAmount().add(amount).compareTo(order.getTotalAmount()) > 0) {
                return false;
            }
            
            // 更新退款金额（会检查版本号）
            order.setRefundedAmount(order.getRefundedAmount().add(amount));
            
            try {
                orderRepository.save(order); // 这里会检查版本号
                
                // 创建退款记录
                createRefundRecord(orderId, amount);
                
                return true;
                
            } catch (ObjectOptimisticLockingFailureException e) {
                // 乐观锁冲突，重试
                continue;
            }
        }
    }
    
    private void createRefundRecord(Long orderId, BigDecimal amount) {
        Refund refund = new Refund();
        refund.setOrderId(orderId);
        refund.setAmount(amount);
        refund.setStatus("SUCCESS");
        refundRepository.save(refund);
    }
}

代码分析：乐观锁通过版本号机制，确保同一时间只有一个线程能成功更新数据。就像给账本加上版本号，每次修改都要检查版本号是否一致，不一致就重新读取最新数据再试。

# 第二层：数据库层面的悲观锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
/**
 * 使用悲观锁的退款服务
 */
@Service
public class PessimisticRefundService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    /**
     * 基于悲观锁的退款处理
     */
    @Transactional(rollbackFor = Exception.class)
    public boolean processRefundWithPessimisticLock(Long orderId, BigDecimal amount) {
        // 使用悲观锁查询订单（SELECT ... FOR UPDATE）
        Order order = orderRepository.findByIdWithLock(orderId).orElse(null);
        if (order == null) {
            return false;
        }
        
        // 检查退款金额
        if (order.getRefundedAmount().add(amount).compareTo(order.getTotalAmount()) > 0) {
            return false;
        }
        
        // 更新退款金额
        order.setRefundedAmount(order.getRefundedAmount().add(amount));
        orderRepository.save(order);
        
        // 创建退款记录
        createRefundRecord(orderId, amount);
        
        return true;
    }
}

/**
 * 订单仓库接口 - 添加悲观锁查询方法
 */
public interface OrderRepository extends JpaRepository<Order, Long> {
    
    /**
     * 使用悲观锁查询订单
     */
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT o FROM Order o WHERE o.id = :orderId")
    Optional<Order> findByIdWithLock(@Param("orderId") Long orderId);
}

代码分析：悲观锁通过 "SELECT ... FOR UPDATE" 锁定数据行，确保其他事务无法同时修改。就像一个人在修改账本时，把账本锁起来，其他人只能等待。

# 第三层：应用层面的分布式锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
/**
 * 使用分布式锁的退款服务
 */
@Service
public class DistributedLockRefundService {
    
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    
    @Autowired
    private RefundService refundService;
    
    private static final String LOCK_PREFIX = "refund:lock:";
    private static final long LOCK_EXPIRE_TIME = 30; // 锁过期时间30秒
    
    /**
     * 基于分布式锁的退款处理
     */
    public boolean processRefundWithDistributedLock(Long orderId, BigDecimal amount) {
        String lockKey = LOCK_PREFIX + orderId;
        
        // 尝试获取分布式锁
        String lockValue = tryLock(lockKey);
        if (lockValue == null) {
            return false; // 获取锁失败
        }
        
        try {
            // 在锁保护下执行退款逻辑
            return refundService.processRefund(orderId, amount);
        } finally {
            // 释放锁
            releaseLock(lockKey, lockValue);
        }
    }
    
    /**
     * 尝试获取锁
     */
    private String tryLock(String lockKey) {
        String lockValue = UUID.randomUUID().toString();
        
        Boolean success = redisTemplate.opsForValue().setIfAbsent(
            lockKey, 
            lockValue, 
            LOCK_EXPIRE_TIME, 
            TimeUnit.SECONDS
        );
        
        return success != null && success ? lockValue : null;
    }
    
    /**
     * 释放锁
     */
    private void releaseLock(String lockKey, String lockValue) {
        String script = 
            "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "    return redis.call('del', KEYS[1]) " +
            "else " +
            "    return 0 " +
            "end";
        
        redisTemplate.execute(
            new DefaultRedisScript<>(script, Long.class),
            Collections.singletonList(lockKey),
            lockValue
        );
    }
}

代码分析：分布式锁通过 Redis 实现跨服务器的并发控制，适用于分布式系统。就像在多个办公室之间共享一个 "会议室预约系统"，确保同一时间只有一个人能使用会议室。

# 第四层：业务层面的幂等控制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
/**
 * 支持幂等的退款服务
 */
@Service
public class IdempotentRefundService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private RefundRepository refundRepository;
    
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    
    /**
     * 幂等退款处理
     */
    @Transactional(rollbackFor = Exception.class)
    public RefundResult processRefundWithIdempotency(RefundRequest request) {
        String idempotencyKey = generateIdempotencyKey(request);
        
        // 检查是否已经处理过
        String processedResult = redisTemplate.opsForValue().get(idempotencyKey);
        if (processedResult != null) {
            // 已经处理过，返回之前的结果
            return JsonUtils.fromJson(processedResult, RefundResult.class);
        }
        
        try {
            // 执行退款逻辑
            boolean success = doRefund(request.getOrderId(), request.getAmount());
            
            RefundResult result = RefundResult.builder()
                .success(success)
                .message(success ? "退款成功" : "退款失败")
                .timestamp(System.currentTimeMillis())
                .build();
            
            // 记录处理结果（设置过期时间）
            redisTemplate.opsForValue().set(
                idempotencyKey, 
                JsonUtils.toJson(result), 
                24, 
                TimeUnit.HOURS
            );
            
            return result;
            
        } catch (Exception e) {
            // 异常情况下不记录幂等key，允许重试
            throw e;
        }
    }
    
    /**
     * 生成幂等key
     */
    private String generateIdempotencyKey(RefundRequest request) {
        return String.format("refund:idempotency:%s:%s:%s", 
            request.getOrderId(), 
            request.getAmount(), 
            request.getIdempotencyToken());
    }
    
    /**
     * 执行实际退款逻辑
     */
    private boolean doRefund(Long orderId, BigDecimal amount) {
        // 这里可以结合乐观锁或悲观锁
        Order order = orderRepository.findById(orderId).orElse(null);
        if (order == null) {
            return false;
        }
        
        if (order.getRefundedAmount().add(amount).compareTo(order.getTotalAmount()) > 0) {
            return false;
        }
        
        order.setRefundedAmount(order.getRefundedAmount().add(amount));
        orderRepository.save(order);
        
        createRefundRecord(orderId, amount);
        
        return true;
    }
}

代码分析：幂等控制确保同一个请求多次执行结果一致。就像银行转账时，即使客户多次点击 "确认转账"，也只会转账一次。

# 事务隔离级别与传播机制

# 隔离级别选择

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
/**
 * 不同隔离级别的退款服务对比
 */
@Service
public class IsolationLevelRefundService {
    
    /**
     * READ_UNCOMMITTED：读未提交（不推荐）
     * 问题：可能读到未提交的脏数据
     */
    @Transactional(isolation = Isolation.READ_UNCOMMITTED)
    public boolean refundWithReadUncommitted(Long orderId, BigDecimal amount) {
        // 可能读到其他事务未提交的退款金额
        Order order = orderRepository.findById(orderId).orElse(null);
        // 问题：如果其他事务回滚，这里读到的数据就是错误的
        return processRefund(order, amount);
    }
    
    /**
     * READ_COMMITTED：读已提交（MySQL默认）
     * 问题：存在不可重复读
     */
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public boolean refundWithReadCommitted(Long orderId, BigDecimal amount) {
        // 第一次读取
        Order order1 = orderRepository.findById(orderId).orElse(null);
        
        // 模拟其他事务修改了数据
        // 其他事务在这里修改了订单退款金额并提交
        
        // 第二次读取，可能得到不同的结果
        Order order2 = orderRepository.findById(orderId).orElse(null);
        
        // 问题：order1和order2的退款金额可能不同
        return processRefund(order2, amount);
    }
    
    /**
     * REPEATABLE_READ：可重复读（推荐）
     * 优点：同一事务中多次读取结果一致
     */
    @Transactional(isolation = Isolation.REPEATABLE_READ)
    public boolean refundWithRepeatableRead(Long orderId, BigDecimal amount) {
        // 第一次读取
        Order order1 = orderRepository.findById(orderId).orElse(null);
        
        // 其他事务修改了数据并提交
        
        // 第二次读取，得到相同的结果
        Order order2 = orderRepository.findById(orderId).orElse(null);
        
        // 优点：order1和order2的退款金额相同
        return processRefund(order1, amount);
    }
    
    /**
     * SERIALIZABLE：串行化
     * 问题：性能太差，基本不用
     */
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public boolean refundWithSerializable(Long orderId, BigDecimal amount) {
        // 所有事务串行执行，性能极差
        return processRefund(orderId, amount);
    }
}

# 传播机制选择

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
/**
 * 不同传播机制的退款服务
 */
@Service
public class PropagationRefundService {
    
    @Autowired
    private OrderService orderService;
    
    @Autowired
    private RefundRecordService refundRecordService;
    
    @Autowired
    private NotificationService notificationService;
    
    /**
     * REQUIRED：默认传播机制（推荐）
     * 如果当前没有事务，就新建一个事务
     * 如果已经存在一个事务，就加入到这个事务中
     */
    @Transactional(propagation = Propagation.REQUIRED)
    public boolean refundWithRequired(Long orderId, BigDecimal amount) {
        try {
            // 更新订单（在同一个事务中）
            orderService.updateRefundAmount(orderId, amount);
            
            // 创建退款记录（在同一个事务中）
            refundRecordService.createRefundRecord(orderId, amount);
            
            // 发送通知（如果失败，整个事务回滚）
            notificationService.sendRefundNotification(orderId, amount);
            
            return true;
            
        } catch (Exception e) {
            // 任何步骤失败，整个事务回滚
            throw e;
        }
    }
    
    /**
     * REQUIRES_NEW：新建事务
     * 总是新建一个事务，如果当前存在事务，就把当前事务挂起
     */
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public boolean refundWithRequiresNew(Long orderId, BigDecimal amount) {
        try {
            // 更新订单（在新事务中）
            orderService.updateRefundAmount(orderId, amount);
            
            // 创建退款记录（在新事务中）
            refundRecordService.createRefundRecord(orderId, amount);
            
            // 发送通知（在独立事务中，即使失败也不影响退款）
            notificationService.sendRefundNotificationWithNewTransaction(orderId, amount);
            
            return true;
            
        } catch (Exception e) {
            // 只有订单和退款记录操作会回滚，通知不影响
            throw e;
        }
    }
    
    /**
     * NESTED：嵌套事务
     * 如果当前存在事务，就在嵌套事务内执行
     * 如果当前没有事务，就新建一个事务
     */
    @Transactional(propagation = Propagation.NESTED)
    public boolean refundWithNested(Long orderId, BigDecimal amount) {
        try {
            // 更新订单（在嵌套事务中）
            orderService.updateRefundAmount(orderId, amount);
            
            // 创建退款记录（在嵌套事务中）
            refundRecordService.createRefundRecord(orderId, amount);
            
            // 发送通知（在嵌套事务中）
            notificationService.sendRefundNotification(orderId, amount);
            
            return true;
            
        } catch (Exception e) {
            // 可以选择回滚到特定保存点
            throw e;
        }
    }
    
    /**
     * NOT_SUPPORTED：非事务方式执行
     * 总是非事务地执行，并挂起任何存在的事务
     */
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public boolean refundWithNotSupported(Long orderId, BigDecimal amount) {
        // 更新订单（非事务方式）
        orderService.updateRefundAmountWithoutTransaction(orderId, amount);
        
        // 创建退款记录（非事务方式）
        refundRecordService.createRefundRecordWithoutTransaction(orderId, amount);
        
        // 发送通知（非事务方式）
        notificationService.sendRefundNotificationWithoutTransaction(orderId, amount);
        
        return true;
    }
}

# 效果验证：数据说话

在我们电商平台部署这套并发控制方案后：

  • 重复退款率：从 0.5% 降低到 0%（完全消除）
  • 数据一致性：财务对账差异从每月 50 笔降低到 0 笔
  • 系统稳定性：退款成功率从 95% 提升到 99.9%
  • 用户体验：退款响应时间从 2 秒降低到 500 毫秒

压测数据对比：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@Test
public void concurrentRefundTest() {
    int threadCount = 100;
    int refundAmount = 100;
    CountDownLatch latch = new CountDownLatch(threadCount);
    
    // 测试原始方案（无并发控制）
    long startTime = System.currentTimeMillis();
    testOriginalRefund(threadCount, refundAmount, latch);
    long originalTime = System.currentTimeMillis() - startTime;
    
    // 测试优化方案（多层并发控制）
    latch = new CountDownLatch(threadCount);
    startTime = System.currentTimeMillis();
    testOptimizedRefund(threadCount, refundAmount, latch);
    long optimizedTime = System.currentTimeMillis() - startTime;
    
    System.out.println("原始方案耗时: " + originalTime + "ms");
    System.out.println("优化方案耗时: " + optimizedTime + "ms");
    
    // 验证结果
    Order order = orderRepository.findById(testOrderId).orElse(null);
    System.out.println("实际退款金额: " + order.getRefundedAmount());
    System.out.println("退款记录数: " + refundRepository.countByOrderId(testOrderId));
    
    // 结果：优化方案确保数据一致性，性能略有提升
}

# 避坑指南：实战中踩过的 5 个坑

# 坑一：事务隔离级别选择错误

踩坑经历：我们使用了默认的 READ_COMMITTED 隔离级别，在高并发退款场景下出现了不可重复读问题。一个事务中两次查询订单退款金额得到了不同的结果，导致退款金额计算错误。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 错误配置：使用READ_COMMITTED
@Transactional(isolation = Isolation.READ_COMMITTED)
public boolean processRefund(Long orderId, BigDecimal amount) {
    // 第一次查询
    Order order1 = orderRepository.findById(orderId).orElse(null);
    BigDecimal currentRefund = order1.getRefundedAmount();
    
    // 其他事务在这里修改了退款金额
    
    // 第二次查询，得到不同的结果
    Order order2 = orderRepository.findById(orderId).orElse(null);
    
    // 问题：currentRefund和order2.getRefundedAmount()可能不同
    if (order2.getRefundedAmount().add(amount).compareTo(order2.getTotalAmount()) > 0) {
        return false;
    }
    
    // 后续处理...
}

解决方案：使用 REPEATABLE_READ 隔离级别。

1
2
3
4
5
6
7
8
9
10
11
12
// 正确配置：使用REPEATABLE_READ
@Transactional(isolation = Isolation.REPEATABLE_READ)
public boolean processRefund(Long orderId, BigDecimal amount) {
    // 在整个事务中，多次读取结果一致
    Order order = orderRepository.findById(orderId).orElse(null);
    
    if (order.getRefundedAmount().add(amount).compareTo(order.getTotalAmount()) > 0) {
        return false;
    }
    
    // 后续处理...
}

预防措施：涉及资金操作的业务，统一使用 REPEATABLE_READ 隔离级别。

# 坑二：事务传播机制配置不当

踩坑经历：退款成功后需要发送通知，我们使用了默认的 REQUIRED 传播机制。结果通知服务失败时，整个退款事务都回滚了，用户看到退款失败，但实际上资金已经扣减。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 错误配置：通知失败导致整个事务回滚
@Transactional(propagation = Propagation.REQUIRED)
public boolean processRefund(Long orderId, BigDecimal amount) {
    // 更新订单退款金额
    orderService.updateRefundAmount(orderId, amount);
    
    // 创建退款记录
    refundRecordService.createRefundRecord(orderId, amount);
    
    // 发送通知（如果失败，整个事务回滚）
    notificationService.sendRefundNotification(orderId, amount); // 可能失败
    
    return true;
}

解决方案：通知服务使用 REQUIRES_NEW 传播机制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 正确配置：通知失败不影响主业务
@Transactional(propagation = Propagation.REQUIRED)
public boolean processRefund(Long orderId, BigDecimal amount) {
    // 更新订单退款金额
    orderService.updateRefundAmount(orderId, amount);
    
    // 创建退款记录
    refundRecordService.createRefundRecord(orderId, amount);
    
    // 发送通知（在独立事务中，失败不影响主业务）
    notificationService.sendRefundNotificationWithNewTransaction(orderId, amount);
    
    return true;
}

// 通知服务使用独立事务
@Service
public class NotificationService {
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void sendRefundNotificationWithNewTransaction(Long orderId, BigDecimal amount) {
        // 发送通知逻辑，失败不影响主事务
    }
}

# 坑三：分布式锁实现有漏洞

踩坑经历：我们实现的分布式锁没有考虑锁过期时间，结果一个退款请求处理时间过长，锁自动过期了，另一个线程又获取了锁，导致并发问题。

1
2
3
4
5
6
7
8
9
// 错误实现：没有设置锁过期时间
public boolean tryLock(String lockKey) {
    String lockValue = UUID.randomUUID().toString();
    
    // 问题：没有设置过期时间，如果服务宕机，锁永远不会释放
    Boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey, lockValue);
    
    return success != null && success;
}

解决方案：设置合理的锁过期时间，并实现锁续期机制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// 正确实现：设置过期时间并支持续期
public class DistributedLock {
    
    private static final long DEFAULT_EXPIRE_TIME = 30; // 默认30秒
    private static final long RENEWAL_TIME = 10;      // 10秒续期一次
    
    public boolean tryLock(String lockKey) {
        String lockValue = UUID.randomUUID().toString();
        
        Boolean success = redisTemplate.opsForValue().setIfAbsent(
            lockKey, 
            lockValue, 
            DEFAULT_EXPIRE_TIME, 
            TimeUnit.SECONDS
        );
        
        if (success != null && success) {
            // 启动锁续期线程
            startRenewalThread(lockKey, lockValue);
            return true;
        }
        
        return false;
    }
    
    /**
     * 启动锁续期线程
     */
    private void startRenewalThread(String lockKey, String lockValue) {
        ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
        
        scheduler.scheduleAtFixedRate(() -> {
            try {
                String script = 
                    "if redis.call('get', KEYS[1]) == ARGV[1] then " +
                    "    return redis.call('expire', KEYS[1], ARGV[2]) " +
                    "else " +
                    "    return 0 " +
                    "end";
                
                redisTemplate.execute(
                    new DefaultRedisScript<>(script, Long.class),
                    Collections.singletonList(lockKey),
                    lockValue,
                    String.valueOf(DEFAULT_EXPIRE_TIME)
                );
            } catch (Exception e) {
                // 续期失败，记录日志
                log.error("锁续期失败: {}", lockKey, e);
            }
        }, RENEWAL_TIME, RENEWAL_TIME, TimeUnit.SECONDS);
    }
}

# 坑四：幂等性设计不完善

踩坑经历：我们的幂等控制只基于订单 ID，结果同一笔订单的不同金额退款也被认为是重复请求，导致用户无法分批退款。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 错误实现：幂等key太简单
private String generateIdempotencyKey(Long orderId) {
    return "refund:idempotency:" + orderId; // 问题：没有考虑退款金额
}

public boolean processRefund(Long orderId, BigDecimal amount) {
    String idempotencyKey = generateIdempotencyKey(orderId);
    
    // 问题：同一订单的不同金额退款被认为是重复请求
    if (redisTemplate.hasKey(idempotencyKey)) {
        return false;
    }
    
    // 处理退款...
}

解决方案：设计更精确的幂等 key。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 正确实现：包含业务关键信息
private String generateIdempotencyKey(RefundRequest request) {
    // 包含订单ID、退款金额、业务标识等
    return String.format("refund:idempotency:%s:%s:%s:%s", 
        request.getOrderId(),           // 订单ID
        request.getAmount(),            // 退款金额
        request.getReason(),            // 退款原因
        request.getIdempotencyToken());  // 幂等令牌
}

public RefundResult processRefund(RefundRequest request) {
    String idempotencyKey = generateIdempotencyKey(request);
    
    // 检查是否已经处理过
    String processedResult = redisTemplate.opsForValue().get(idempotencyKey);
    if (processedResult != null) {
        return JsonUtils.fromJson(processedResult, RefundResult.class);
    }
    
    // 处理退款...
}

# 坑五：异常处理不完整

踩坑经历：退款过程中出现异常时，我们只记录了日志，没有完整回滚所有操作，导致数据不一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 错误实现：异常处理不完整
@Transactional
public boolean processRefund(Long orderId, BigDecimal amount) {
    try {
        // 更新订单
        orderService.updateRefundAmount(orderId, amount);
        
        // 创建退款记录
        refundRecordService.createRefundRecord(orderId, amount);
        
        // 调用外部支付接口
        paymentService.refund(orderId, amount);
        
        return true;
        
    } catch (Exception e) {
        // 问题：只记录日志，没有回滚
        log.error("退款失败", e);
        return false;
    }
}

解决方案：完整的异常处理和事务回滚。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 正确实现：完整的异常处理
@Transactional(rollbackFor = Exception.class)
public boolean processRefund(Long orderId, BigDecimal amount) {
    try {
        // 更新订单
        orderService.updateRefundAmount(orderId, amount);
        
        // 创建退款记录
        refundRecordService.createRefundRecord(orderId, amount);
        
        // 调用外部支付接口
        boolean paymentSuccess = paymentService.refund(orderId, amount);
        
        if (!paymentSuccess) {
            throw new RefundException("支付接口退款失败");
        }
        
        return true;
        
    } catch (RefundException e) {
        // 业务异常，回滚事务
        log.error("退款业务失败: orderId={}, amount={}", orderId, amount, e);
        throw e; // 重新抛出，触发事务回滚
        
    } catch (Exception e) {
        // 系统异常，回滚事务
        log.error("退款系统异常: orderId={}, amount={}", orderId, amount, e);
        throw new RefundException("系统异常", e);
    }
}

# 监控与运营：让并发问题可观测

# 实时监控指标

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
/**
 * 退款监控服务
 */
@Component
public class RefundMonitorService {
    
    @Autowired
    private MeterRegistry meterRegistry;
    
    private final Counter refundSuccessCounter;
    private final Counter refundFailureCounter;
    private final Counter duplicateRefundCounter;
    private final Timer refundProcessTimer;
    
    public RefundMonitorService(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
        
        this.refundSuccessCounter = Counter.builder("refund.success.count")
            .description("退款成功次数")
            .register(meterRegistry);
            
        this.refundFailureCounter = Counter.builder("refund.failure.count")
            .description("退款失败次数")
            .register(meterRegistry);
            
        this.duplicateRefundCounter = Counter.builder("refund.duplicate.count")
            .description("重复退款次数")
            .register(meterRegistry);
            
        this.refundProcessTimer = Timer.builder("refund.process.duration")
            .description("退款处理耗时")
            .register(meterRegistry);
    }
    
    /**
     * 记录退款成功
     */
    public void recordRefundSuccess(Long orderId, BigDecimal amount) {
        refundSuccessCounter.increment(
            Tags.of("order_id", String.valueOf(orderId))
        );
    }
    
    /**
     * 记录退款失败
     */
    public void recordRefundFailure(Long orderId, BigDecimal amount, String reason) {
        refundFailureCounter.increment(
            Tags.of(
                "order_id", String.valueOf(orderId),
                "reason", reason
            )
        );
    }
    
    /**
     * 记录重复退款
     */
    public void recordDuplicateRefund(Long orderId) {
        duplicateRefundCounter.increment(
            Tags.of("order_id", String.valueOf(orderId))
        );
    }
    
    /**
     * 记录退款处理时间
     */
    public <T> T recordRefundTime(Supplier<T> supplier) {
        return Timer.Sample.start(meterRegistry)
            .stop(refundProcessTimer)
            .recordCallable(supplier::get);
    }
}

# 告警规则配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 告警规则配置
refund:
  alerts:
    # 重复退款告警
    duplicate-refund:
      enabled: true
      threshold: 1      # 出现1次重复退款就告警
      severity: critical
      
    # 退款失败率告警
    refund-failure-rate:
      enabled: true
      threshold: 0.05   # 失败率超过5%告警
      window: 5m        # 5分钟窗口
      severity: warning
      
    # 退款处理时间告警
    refund-process-time:
      enabled: true
      threshold: 2000   # 处理时间超过2秒告警
      severity: warning
      
    # 并发锁竞争告警
    lock-contention:
      enabled: true
      threshold: 10     # 锁等待超过10次告警
      severity: warning

# 数据一致性检查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
/**
 * 数据一致性检查服务
 */
@Component
public class DataConsistencyChecker {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private RefundRepository refundRepository;
    
    /**
     * 检查退款数据一致性
     */
    @Scheduled(fixedRate = 300000) // 每5分钟检查一次
    public void checkRefundConsistency() {
        List<Order> orders = orderRepository.findOrdersWithRefund();
        
        for (Order order : orders) {
            checkOrderRefundConsistency(order);
        }
    }
    
    /**
     * 检查单个订单的退款一致性
     */
    private void checkOrderRefundConsistency(Order order) {
        // 计算退款记录总金额
        BigDecimal totalRefundAmount = refundRepository
            .sumAmountByOrderId(order.getId())
            .orElse(BigDecimal.ZERO);
        
        // 检查是否一致
        if (order.getRefundedAmount().compareTo(totalRefundAmount) != 0) {
            // 数据不一致，发送告警
            alertService.sendDataInconsistencyAlert(
                order.getId(),
                order.getRefundedAmount(),
                totalRefundAmount
            );
            
            // 记录到数据库，便于后续修复
            recordInconsistency(order.getId(), order.getRefundedAmount(), totalRefundAmount);
        }
    }
    
    /**
     * 记录数据不一致问题
     */
    private void recordInconsistency(Long orderId, BigDecimal orderRefundAmount, 
                                   BigDecimal actualRefundAmount) {
        DataInconsistency inconsistency = new DataInconsistency();
        inconsistency.setOrderId(orderId);
        inconsistency.setOrderRefundAmount(orderRefundAmount);
        inconsistency.setActualRefundAmount(actualRefundAmount);
        inconsistency.setDifference(orderRefundAmount.subtract(actualRefundAmount));
        inconsistency.setDetectedTime(new Date());
        inconsistency.setStatus("PENDING");
        
        dataInconsistencyRepository.save(inconsistency);
    }
}

# 总结与延伸

# 核心观点提炼

  1. 并发控制要多层次：数据库锁、分布式锁、业务幂等，多层防护更安全
  2. 事务隔离要合理：资金操作必须使用 REPEATABLE_READ，避免不可重复读
  3. 异常处理要完整：任何异常都要触发事务回滚，确保数据一致性
  4. 监控告警要完善：实时监控并发指标，及时发现问题

# 技术延伸

分布式事务：在微服务架构中，可能需要使用 Saga 模式、TCC 模式等分布式事务解决方案。

消息队列：可以使用消息队列实现最终一致性，适合对实时性要求不高的场景。

数据库分库分表：在超大规模系统中，需要考虑分库分表对并发控制的影响。

# 实践建议

  1. 立即行动：检查现有退款逻辑，识别并发安全风险
  2. 分步实施：先加数据库锁，再加分布式锁，最后完善幂等控制
  3. 充分测试：使用并发测试工具验证方案有效性
  4. 持续监控：建立完善的监控体系，及时发现问题

记住，并发退款的安全控制不是可有可无的 "锦上添花"，而是保障资金安全的 "生命线"。一次并发事故可能导致巨大的资金损失和用户信任危机。科学设计并发控制方案，完善监控告警机制，才能确保系统在高并发场景下的数据一致性和资金安全。

已有0条评论
  • 快来做第一个评论的人吧~