当前实现#

1
String msgId =
2
        msgs.get(0).getMsgId();
3

4
String key =
5
        RedisConst.PROMO_RESUME_MESSAGE
6
                + msgId;
7

8
RBucket<Object> bucket =
9
        redissonClient.getBucket(key);
10

11
boolean firstConsume =
12
        bucket.trySet("consume");
13

14
if (!firstConsume) {
15
    return ConsumeConcurrentlyStatus
16
            .CONSUME_SUCCESS;
17
}

同一 msgId 再投递时，trySet 失败并直接返回消费成功。它能阻止正常重试重复创建订单。

标记前置的崩溃窗口#

标记在订单落库之前写入：

1
写 consume 标记
2
    ↓
3
解析消息
4
    ↓
5
保存订单
6
    ↓
7
写 userId:skuId -> orderId

代码捕获普通异常时会删除标记并返回稍后重试，但如果进程在写标记后突然退出、机器断电或 JVM 被强制终止，catch 无法执行。消息重投后看到标记存在，会直接返回成功，订单可能永远没有创建。

因此当前消费幂等属于“先占位”方案，但缺少“处理中/成功”状态、TTL 和数据库唯一键兜底。

解析消息#

1
MessageExt message =
2
        msgs.get(0);
3

4
String messageContent =
5
        new String(message.getBody());
6

7
OrderInfoParam orderInfoParam =
8
        JSON.parseObject(
9
                messageContent,
10
                OrderInfoParam.class);
11

12
Long userId =
13
        orderInfoParam.getUserId();
14

15
Long skuId =
16
        orderInfoParam
17
                .getOrderDetailList()
18
                .get(0)
19
                .getSkuId();

Producer 使用 UTF-8 编码，Consumer 使用平台默认字符集解码。若部署默认字符集不是 UTF-8，包含中文的商品名或地址可能出现编码问题；当前 Windows/服务器实际字符集未验证。

保存订单#

代码路径：duolaimall-order/order-service/src/main/java/com/cskaoyan/mall/order/service/impl/OrderServiceImpl.java
关键方法：saveSeckillOrder

1
@Transactional(rollbackFor = Exception.class)
2
public Long saveSeckillOrder(
3
        OrderInfoParam orderInfoParam) {
4

5
    OrderInfo orderInfo =
6
            orderInfoConverter
7
                    .convertOrderInfoParam(
8
                            orderInfoParam);
9

10
    orderInfo.setOrderStatus(
11
            OrderStatus.UNPAID.name());
12
    orderInfo.sumTotalAmount();
13

14
    orderInfo.setOutTradeNo(
15
            UUID.randomUUID()
16
                    .toString()
17
                    .replaceAll("-", ""));
18

19
    orderInfo.setTradeBody(
20
            orderInfo.getOrderDetailList()
21
                    .get(0)
22
                    .getSkuName());
23

24
    orderInfo.setOrderType(
25
            OrderType.PROMO_ORDER.name());
26

27
    orderInfo.setExpireTime(
28
            DateUtil.datePlusMinutes(
29
                    new Date(), 3));
30

31
    return saveOrderInfo(orderInfo);
32
}

saveSeckillOrder 自身从消费者通过 Spring Bean 调用，外层事务可以覆盖内部保存主表和明细。秒杀订单类型标为 PROMO_ORDER，过期时间设置 3 分钟。

但方法末尾“发送超时取消消息、回补秒杀库存”仍是 TODO。设置 expireTime 不会自动产生定时任务。

回写状态与剩余库存#

1
List<SeckillGoods> goodsList =
2
        getCurrentDayGoodsList();
3

4
for (SeckillGoods goods : goodsList) {
5
    goods.setStatus(
6
            SeckillGoodsStatus.FINISHED.name());
7
    seckillGoodsMapper.updateById(goods);
8
}
9

10
RMap<String, String> stockMap =
11
        redissonClient.getMap(
12
                RedisConst
13
                        .PROMO_SECKILL_GOODS_STOCK,
14
                new StringCodec());
15

16
stockMap.keySet().forEach(skuId -> {
17
    String remainStock =
18
            stockMap.get(skuId);
19

20
    UpdateWrapper<SeckillGoods> wrapper =
21
            new UpdateWrapper<>();
22

23
    wrapper.eq("sku_id", skuId);
24
    wrapper.eq(
25
            "DATE_FORMAT(start_time,'%Y-%m-%d')",
26
            DateUtil.formatDate(new Date()));
27
    wrapper.set(
28
            "stock_count", remainStock);
29

30
    seckillGoodsMapper.update(
31
            null, wrapper);
32
});

删除缓存#

1
redissonClient.getKeys()
2
        .deleteByPattern("promo:*");
3

4
LocalCacheHelper.removeAll();

这会同时删除活动商品、库存、用户防重、事务回查、消费标记和订单轮询结果。若清理与未完成事务回查或消息消费重叠，可能提前删除仍在使用的协调状态。

入口是 GET /clear/cache，仓库内没有看到本次已验证的定时任务；访问控制取决于外部 Gateway 规则，当前未知。

Lua 解决了什么#

1
同一个 Redis 实例、同一个库存 Hash：
2
  检查库存 + 扣减库存
3
  作为一个 Lua 原子操作执行

它可以阻止并发把 Redis 库存扣成负数。

Lua 没解决什么#

• 用户是否重复提交；
• 消息是否发送到正确 Broker；
• 订单是否最终保存；
• 消费者是否崩溃；
• 未支付订单是否回补库存；
• Redis 数据与 MySQL 活动库存是否持续一致。

RocketMQ 事务消息解决了什么#

当 Producer 能正常与 Broker 和 Redis 协作时：

• Lua 返回成功，消息提交并可消费；
• Lua 返回库存不足，消息回滚；
• Broker 不确定时，通过 Redis 事务标记回查。

RocketMQ 事务消息没解决什么#

• Producer 与 Consumer 地址配置是否一致；
• Consumer 业务一定只执行一次；
• Redis 扣库存后订单永远不会丢；
• 订单超时回补；
• 客户端请求参数可信；
• Redis 与订单数据库是一个原子事务。

当前幂等层次#

正常成功#

1. 本地状态为有库存；
2. 用户 Set 首次添加成功；
3. Producer 发送 Half Message；
4. Lua 扣减后返回非负；
5. 写事务状态 success，提交消息；
6. Controller 返回“正在排队”；
7. Consumer 占用 msgId 标记；
8. 订单主从表事务保存成功；
9. 写 promo:orders[userId:skuId] = orderId；
10. 下一次轮询返回“下单成功”。

库存不足#

1. 本地状态可能仍是有库存；
2. 用户 Set 添加成功；
3. Lua 返回 -1；
4. 本地状态改为无库存；
5. 事务消息回滚；
6. Controller 返回“已售罄”。

当前分支不删除用户 Set 标记，但商品已售罄时通常没有再次购买机会。

消息发送明确失败#

submitOrderInTransaction 删除用户 Set 中的 SKU，并返回“请稍后重试”。用户可以重新提交。

本地事务结果未知#

方法返回“请稍后重试”，但没有删除用户 Set。用户直接重试会得到“重复抢购”；真正结果依赖 Broker 后续回查和 Redis transaction Bucket。

Producer 在 Lua 与结果标记之间退出#

Lua 扣库存和 stateBucket.set("success") 是两条独立 Redis 操作。若进程在 Lua 成功后、写入 transactionId 结果前退出，Redis 库存已经减少，Broker 回查却只能得到 UNKNOW。当前代码没有按 transactionId 回补这次扣减或从其他业务事实恢复提交结论，因此存在“库存已扣、消息长期未知或最终未提交”的候选窗口。

Consumer 普通异常#

catch 会删除 msgId 消费标记并返回 RECONSUME_LATER，RocketMQ 可以重投。

Consumer 进程突然退出#

若退出发生在 msgId 标记写入后、订单提交前，catch 不会运行。消息重投时标记已存在，Consumer 直接返回成功，形成库存已扣但订单缺失窗口。

订单成功但结果 Map 写失败#

订单数据库已经提交，异常会删除消费标记并让消息重试。下一次消费可能再次创建订单，因为订单表没有看到与 msgId 或“用户 + SKU + 活动”绑定的唯一键。

亮点#

1. 活动数据提前进入 Redis，降低活动开始时数据库压力；
2. 本地状态位能在售罄后快速失败；
3. 用户 Set 使用原子添加限制重复提交；
4. 库存 Hash 使用 StringCodec，便于 Lua 操作；
5. Lua 原子完成库存检查与扣减；
6. RocketMQ 事务消息让库存失败时订单消息不提交；
7. Broker 回查通过 Redis transactionId 标记恢复决策；
8. Consumer 设计了消息防重；
9. 异步下单使用“排队中 + 轮询”，不提前谎报订单已落库。

真实取舍#

• 本地状态速度快，但多实例不共享，只适合做旁路过滤；
• Redis 库存吞吐高，但需要活动结束回写和故障恢复；
• 事务消息缩小了库存与消息的不一致窗口，但引入回查状态管理；
• 前置消费标记阻止常规重复，却产生进程崩溃窗口；
• 轮询实现简单，但会增加请求量并依赖结果 Map 生命周期。

服务端重建提交参数#

提交只接收最小标识：

1
{
2
  "skuId": 101,
3
  "orderCode": "<一次性下单码>",
4
  "addressId": 88,
5
  "requestId": "<客户端幂等号>"
6
}

服务端从 Redis 活动商品重建商品名、价格、数量和时间，拒绝客户端提交的金额快照。

下单码#

• 使用高熵随机值；
• Redis 保存 code -> userId + skuId + activityId；
• 设置短 TTL；
• 提交时原子消费一次；
• 与活动时间、用户和 SKU 同时校验。

用户防重#

使用活动维度业务键：

1
unique = activityId + userId + skuId

把“提交中、库存成功、订单成功、失败可重试”设计成状态，而不是只有一个永久 Set member。

消费幂等#

一种演进：

1
订单数据库唯一键：
2
  unique(message_transaction_id)
3
或
4
  unique(activity_id, user_id, sku_id)
5

6
数据库事务：
7
  插入幂等记录
8
  保存订单主表
9
  保存订单明细
10
  提交后写/刷新轮询结果

这样消息重投以数据库最终事实为准，不依赖 Redis 前置标记。

库存补偿#

• 秒杀订单发送更短的延迟关闭消息；
• 关闭时条件更新订单状态；
• 订单确实未支付才执行 Lua 回补；
• 回补操作以订单 ID 幂等；
• 对 Redis 扣减成功但长时间没有订单的事务做扫描和补偿；
• 活动结束前等待在途消息或使用状态化清理，而不是直接删除全部协调 key。

基础设施配置#

• Producer 与 Consumer 共用配置中心地址；
• 不在源码中硬编码；
• 设置消息 key，便于追踪一笔抢购；
• 显式 UTF-8 解码；
• 事务回查标记和消费结果设置合理 TTL；
• 监控 Half Message 回查、重试、死信和订单缺口。