减库存成功但生成订单失败该怎么办？

📌 一、问题背景

在高并发秒杀系统中，“减库存成功但生成订单失败”是一个典型的分布式一致性问题。该问题通常出现在库存与订单两个独立系统之间的非原子操作场景。

例如在秒杀流程中：

• Redis 或 MySQL 扣减库存成功
• 但订单服务宕机、超时或异常
• 最终导致“库存少了，但订单不存在”

本质问题：库存扣减与订单创建无法保证强一致性。

🎯 二、核心原理

该问题的核心在于分布式系统中的事务边界被拆分：

• 库存服务负责扣减库存
• 订单服务负责创建订单
• 两者通过 RPC 或 MQ 异步协作

由于没有全局事务控制，就会出现：

库存成功 → 订单失败 → 数据不一致

解决思路围绕三大方向：

• 补偿机制（回滚库存）
• 事务一致性（分布式事务）
• 最终一致性（MQ异步对账）

📊 三、数据结构分析

通常涉及以下核心表结构：

关键点在于：库存与订单必须解耦，但必须可追溯。

⚙️ 四、算法分析

常见解决方案本质是三种策略组合：

1. 事务补偿算法（TCC）
2. 本地消息表 + MQ 确认机制
3. 重试 + 幂等消费

核心思想：

将“强一致性”转为“最终一致性”

算法流程可以抽象为：

1. 扣减库存成功 → 写入事务日志
2. 发送 MQ 消息创建订单
3. 消费失败 → 自动重试
4. 超时未成功 → 补偿回滚库存

🔄 五、执行流程

典型秒杀执行流程如下：

用户请求
↓
Redis预扣库存
↓
MySQL扣库存成功
↓
MQ发送创建订单消息
↓
订单服务消费消息
↓
订单创建失败（异常）
↓
重试机制 / 补偿机制触发
↓
数据最终一致

关键点：所有失败必须可恢复，而不是直接丢失。

📌 六、实际案例

以电商秒杀为例：

• 用户抢购成功，库存 -1
• 订单服务由于数据库连接池满导致创建失败
• MQ 消息未确认消费成功
• 系统触发重试机制

最终处理方案：

• 订单服务消费失败 → 重新投递 MQ
• 超过最大重试次数 → 写入死信队列
• 人工或定时任务补偿处理

⚠️ 七、优缺点分析

❓ 八、面试常见问题

• 库存扣减成功如何保证订单一定生成？
• 如何避免 MQ 消息丢失？
• 如何设计幂等消费？
• 如何处理订单创建失败回滚库存？

🚀 九、总结

减库存成功但订单失败，本质是分布式系统中的最终一致性问题。

解决方案核心思路：

• 不要追求强一致
• 使用 MQ 保证异步可靠投递
• 通过补偿机制保证最终一致性
• 所有操作必须支持幂等

一句话总结：不让系统“瞬间正确”，而是让系统“最终正确”。