乐观锁重试失败时怎样结合Redis预扣减做最终一致性保障？

乐观锁重试失败时怎样结合Redis预扣减做最终一致性保障？

该提问与当前博客内容无直接关联。

乐观锁重试失败时，结合Redis预扣减实现最终一致性保障，是一种在分布式高并发场景下兼顾性能与数据可靠性的高级架构模式。该方案的核心思想是将库存扣减操作拆分为两个阶段：快速预扣减阶段与异步最终落地阶段，通过引入Redis作为高速缓存层和消息队列作为异步协调器，来应对乐观锁在数据库层更新失败带来的挑战。其核心目标是：在保证库存不超卖的前提下，最大化系统吞吐量，并确保数据库与缓存数据的最终一致性。

一、 方案架构与核心流程

下图展示了该方案的核心数据流与组件交互：

Mermaid

预览

源码

库存充足

库存不足

成功

失败（版本冲突/库存不足）

用户下单请求

Redis预扣减检查

Redis原子扣减库存

立即返回“库存不足”

生成预扣减凭证并返回用户

发送扣减消息至MQ

消息队列 MQ

消息消费者

数据库乐观锁扣减

更新数据库， 删除Redis预扣记录

触发补偿机制：1. 回滚Redis库存2. 通知订单服务取消

流程结束

二、 关键组件与实现细节

1. Redis预扣减层

Redis层负责承载绝大部分的读流量和扣减校验，其操作必须是原子性的。

• 数据结构设计：

      
  
        
  
          
  Java
  
        
  
        
  
          
  // Key: stock:product:{productId}
  // Value: 可用库存数量 (Integer)
  // 额外使用一个Hash结构记录预扣详情，用于补偿
  // Key: stock_lock:order:{orderId}
  // Field-Value: productId -> lockedQuantity
  
  
          
          
        
  
        
      
  
    
  

• 原子扣减Lua脚本：
  为避免网络往返和保证原子性，扣减操作应通过Lua脚本执行。

      
  
        
  
          
  lua
  
        
  
        
  
          
  -- KEYS[1]: 库存Key, ARGV[1]: 扣减数量
  local currentStock = tonumber(redis.call('GET', KEYS[1]))
  if (currentStock == nil) then
      -- 初始化库存，通常从数据库加载
      return -1
  end
  if (currentStock >= tonumber(ARGV[1])) then
      redis.call('DECRBY', KEYS[1], ARGV[1])
      return 1 -- 扣减成功
  else
      return 0 -- 库存不足
  end
  
  
          
          
        
  
        
      
  
    
  

• 预扣记录：扣减成功后，需将订单ID、商品ID、扣减数量写入一个有过期时间的Hash中，作为后续数据库扣减或补偿的依据。

2. 异步落地层（数据库最终一致性）

此层消费消息队列中的扣减任务，尝试完成数据库的最终扣减。

• 消费者逻辑（数据库乐观锁更新） ：

      
  
        
  
          
  Java
  
        
  
        
  
          
  @Service
  public class StockDeductConsumer {
      @Autowired
      private ProductStockMapper stockMapper;
      
      @RabbitListener(queues = "stock.deduct.queue")
      public void handleDeductMessage(StockDeductMessage message) {
          int maxRetries = 3;
          int retryCount = 0;
          boolean success = false;
          
          while (retryCount < maxRetries && !success) {
              // 1. 查询当前库存和版本号
              ProductStock stock = stockMapper.selectForUpdate(message.getProductId());
              if (stock.getAvailableStock() < message.getQuantity()) {
                  // 库存不足，触发补偿
                  triggerCompensation(message.getOrderId(), message.getProductId(), message.getQuantity());
                  return;
              }
              // 2. 尝试乐观锁更新
              int rows = stockMapper.optimisticDeduct(
                  message.getProductId(),
                  message.getQuantity(),
                  stock.getVersion() // 传入旧版本号
              );
              if (rows > 0) {
                  success = true;
                  // 3. 成功则清理Redis中的预扣记录
                  redisTemplate.delete("stock_lock:order:" + message.getOrderId());
              } else {
                  // 更新失败，版本冲突，等待后重试
                  retryCount++;
                  Thread.sleep(50 * retryCount); // 指数退避
              }
          }
          if (!success) {
              // 重试多次仍失败，触发补偿
              triggerCompensation(message.getOrderId(), message.getProductId(), message.getQuantity());
          }
      }
  }
  
  
          
          
        
  
        
      
  
    
  

      
  
        
  
          
  XML
  
        
  
        
  
          
  <!-- MyBatis Mapper 乐观锁更新SQL -->
  <update id="optimisticDeduct">
      UPDATE product_stock
      SET available_stock = available_stock - #{quantity},
          version = version + 1,
          updated_at = NOW()
      WHERE product_id = #{productId}
        AND version = #{oldVersion}
        AND available_stock >= #{quantity}
  </update>
  
  
          
          
        
  
        
      
  
    
  

3. 补偿机制（最终一致性的关键）

当数据库乐观锁更新最终失败（如重试超限、库存不足）时，必须触发补偿，回滚Redis预扣的库存，并通知业务方（如订单服务）。

• 补偿服务实现：

      
  
        
  
          
  Java
  
        
  
        
  
          
  @Service
  public class StockCompensationService {
      public void compensate(String orderId, Long productId, Integer quantity) {
          // 1. 回滚Redis库存（原子增加）
          String stockKey = "stock:product:" + productId;
          redisTemplate.opsForValue().increment(stockKey, quantity);
          
          // 2. 删除预扣记录
          String lockKey = "stock_lock:order:" + orderId;
          redisTemplate.delete(lockKey);
          
          // 3. 发送库存扣减失败事件，通知订单服务取消订单或标记为异常
          eventPublisher.publishEvent(new StockDeductFailedEvent(orderId, productId, quantity));
          
          // 4. （可选）记录补偿日志，用于对账
          log.warn("Stock deduction compensated for order: {}, product: {}, quantity: {}", 
                   orderId, productId, quantity);
      }
  }
  
  
          
          
        
  
        
      
  
    
  

• 补偿的触发时机：

  1. 数据库乐观锁更新失败，且重试达到上限。
  2. 消息消费时发现数据库记录中库存不足。
  3. 定时任务扫描“预扣记录表”或Redis中过期的预扣Key，对长时间未确认的预扣进行反向补偿（防止消息丢失）。

三、 方案优势与风险控制

维度	优势	风险与应对措施
性能	99%的请求在Redis层完成，响应极快，数据库压力小。	Redis宕机：需有Redis高可用（主从、集群）和快速故障转移机制。
数据一致性	通过异步消息和补偿机制，保证数据库与缓存的最终一致。	消息丢失：MQ需配置持久化、生产者确认、消费者手动ACK。
用户体验	快速返回预扣结果，订单创建体验流畅。	预扣后最终失败：需有完善的订单状态机和用户通知（如取消订单、退款）。
系统可靠性	组件解耦，任一环节故障（除Redis外）不影响核心下单流程。	补偿风暴：在极端失败情况下，需对补偿操作进行限流和降级。

四、 总结与适用场景

此方案本质上是 “缓存预扣 + 异步落地 + 补偿回滚” 的分布式事务模式，它用最终一致性换取了高并发性能和系统可用性。它特别适用于以下场景：

1. 秒杀、大促等高并发峰值场景：能将数据库QPS降低数个数量级。
2. 库存数据对实时绝对一致性要求不苛刻：允许秒级的数据延迟。
3. 业务上能够接受小概率的“超售-补偿” ：即极少数情况下，用户下单成功但后续因库存不足被取消。

实施此方案的关键在于：确保Redis操作的原子性、保证消息的可靠投递、设计完备的补偿与对账系统。在实际生产中，还需配套实施库存预热、限流降级、全链路监控与告警，形成一个完整的弹性高可用库存解决方案。