电商系统中超卖和重复下单问题思考

在电商系统，尤其是使用SpringCloud架构时，应对“超卖”和“重复下单”是两个核心的高并发挑战。
这通常需要通过分布式锁、幂等性设计、数据库锁与乐观锁等多种技术手段组合解决。

问题类型	解决方案	核心实现要点	适用场景/说明
超卖问题	悲观锁	数据库层面使用 SELECT … FOR UPDATE 锁定商品记录	数据一致性要求高，但并发性能要求较低的场景。
	乐观锁	在数据表中增加版本号（version）字段，更新时校验版本。SQL示例：UPDATE … SET stock=stock-1, version=version+1 WHERE id=#{id} AND version=#{version} 。	推荐使用。适用于读多写少、并发量较高的场景。失败后可通过重试机制弥补。
	Redis原子操作	利用Redis单线程特性，通过INCR或DECR命令操作库存。	性能极高，适合秒杀等极致并发场景。需处理Redis与数据库的数据同步。
	Redis + Lua脚本	将查询库存、判断、扣减等多个操作写在一个Lua脚本中，由Redis原子执行。	性能最佳方案之一。Lua脚本的原子性替代了分布式锁，无锁设计更高效。
	分布式锁	使用Redisson等库，在扣减库存前获取锁，确保同一时间只有一个服务实例能操作库存。	保证强一致性，但性能有损耗，需设置合理的锁超时时间。
重复下单问题	前端防重	用户提交后，通过JavaScript将按钮置灰或显示Loading状态。	防君子不防小人，需与后端措施结合。
	Token机制（幂等）	1. 提交前从服务端获取唯一Token。2. 提交订单时携带该Token。3. 后端校验Redis中的Token是否存在，校验后立即删除。	核心解决方案。确保同一Token的请求仅被处理一次。
	数据库唯一索引	为订单表的关键字段（如订单号，或用户ID + 商品ID + 活动ID的组合）创建唯一索引。	最可靠的防重复兜底方案。即使请求穿透到数据库，插入操作也会失败。
	分布式锁	以用户ID + 商品ID等为Key，在创建订单前尝试获取分布式锁。	防止同一用户瞬间发起多个相同订单的请求。

架构与细节优化
在SpringCloud架构中，除了上述核心技术，一些全局设计和优化细节同样重要：

1. 幂等性设计是基石：
   在分布式系统中，网络超时、服务重试是常态，必须假定任何操作都可能重复。因此，所有核心接口，特别是支付回调接口，都必须实现幂等性。这通常通过校验唯一的业务流水号来实现

2. 数据同步与一致性：
   如果采用Redis预扣库存，需要一套可靠的机制来保证最终同步到数据库。可以考虑通过消息队列
   或定时任务来同步数据。同时，要设计缓存与数据库的双保障机制，例如先更新数据库再删除缓存，并辅以定时校对任务

3. 熔断与降级：
   在SpringCloud中，可以利用Hystrix或Sentinel对库存服务、订单服务进行熔断和降级，防止在系统压力过大时导致雪崩。

方案组合建议

在实际项目中，通常需要组合使用多种方案来构建一个健壮的系统。

针对超卖问题，推荐两种组合：

高性能组合（适用于秒杀）：Redis Lua脚本 + 消息队列。

1.在Redis中完成极限并发下的库存扣减。
2.扣减成功后，发送消息到MQ，由消费者异步进行数据库订单的创建和库存的同步。这套组合能将数据库的压力降到最低。

平衡型组合（适用于普通抢购）：乐观锁 + 重试机制。

1.在数据库层面通过乐观锁控制并发。
2.在应用层为更新失败的操作添加有限次数的重试，提升用户体验。

针对重复下单问题，一个可靠的组合是：

前端防重 + Token幂等 + 数据库唯一索引。
1.前端提交订单后，将按钮置灰。
2.服务端通过Token机制拦截绝大部分重复请求。
3.数据库唯一索引作为最终且最可靠的防线。