商城大促秒杀场景复盘

商城大促秒杀场景的核心挑战是高并发下的系统稳定性（高可用）、库存准确性（防超卖） 和用户体验流畅性的平衡。以下是一套完整的解决方案，涵盖架构设计、技术措施、流程优化及交互设计。

一、核心目标与挑战分析

核心目标：支撑10万+并发请求，库存零超卖，用户操作响应时间<500ms，抢购流程清晰无歧义。
核心挑战：

瞬时流量峰值（可能是日常的100倍以上）导致系统过载；
分布式环境下库存扣减的原子性难以保证；
高延迟或失败提示导致用户重复操作，进一步加剧系统压力。

二、高可用保障方案

通过“分层限流+削峰填谷+冗余容错”构建高可用架构，从前端到后端逐层拦截无效流量，确保核心流程稳定。

1. 前端层：流量过滤与体验优化

预加载与静态化：秒杀页面提前静态化（HTML+CSS+JS），通过CDN分发，减少动态请求；商品信息（图片、描述）预加载到本地缓存。
按钮防重复点击：点击后立即置灰并显示loading，避免用户重复提交（前端防抖：300ms内屏蔽二次点击）。
本地限流：同一用户（基于cookie/用户ID）5秒内最多发起1次请求，超出则提示“请稍后再试”。
实时状态反馈：通过倒计时（精确到秒）、库存进度条（如“剩余20%”）传递活动状态，减少用户焦虑。

2. API网关层：流量拦截与分发

限流熔断：基于Nginx/OpenResty设置全局限流（如10万QPS），超出部分直接返回“系统繁忙，请重试”；对异常IP（如短时间内请求>100次）临时拉黑10分钟。
请求过滤：校验用户登录状态、活动参与资格（如是否在白名单），无效请求直接拦截。
动态路由：将秒杀请求路由到专门的秒杀服务集群，与普通业务服务隔离，避免相互影响。

3. 应用服务层：负载均衡与弹性伸缩

服务集群化：秒杀服务部署多实例（如20台服务器），通过K8s实现自动扩缩容（根据CPU利用率>70%时自动增加实例）。
服务降级：非核心功能（如商品详情页推荐、评价展示）临时关闭，仅保留“抢购”核心接口。
接口幂等性：通过请求唯一ID（如UUID）去重，同一请求重复到达时直接返回缓存结果，避免重复处理。

4. 中间件层：削峰填谷与异步化

消息队列削峰：所有秒杀请求先进入MQ（如RabbitMQ），应用服务异步消费（消费速率可配置，如2万/秒），避免直接冲击数据库。
缓存隔离：秒杀专用Redis集群（独立于普通业务缓存），配置主从+哨兵模式，确保缓存高可用；设置合理内存淘汰策略（如allkeys-lru）。
熔断降级：使用Sentinel/Hystrix监控服务依赖（如Redis、MQ），当依赖故障时快速返回默认结果（如“活动太火爆，请稍后再试”）。

5. 监控与容灾：实时感知与快速恢复

全链路监控：通过Prometheus+Grafana监控关键指标（QPS、响应时间、库存剩余、MQ堆积量），设置阈值告警（如响应时间>1s时触发告警）。
多活部署：核心服务（秒杀、支付）跨机房部署，当主机房故障时，通过DNS切换到备用机房。
应急预案：提前准备“流量开关”，当系统接近极限时，手动降低限流阈值（如从10万QPS降到5万），优先保障部分用户可用。

三、防超卖解决方案

通过“多级校验+原子操作”确保库存扣减的准确性，从缓存到数据库层层把关。

1. 库存预加载与缓存校验

缓存预热：活动开始前1小时，将商品库存（如1000件）加载到Redis，以seckill:stock:{商品ID}为key，值为库存数量（如1000）。
Redis原子扣减：用户抢购请求到达时，先通过Redis的DECR命令预扣减库存（如DECR seckill:stock:1001），若结果>=0则允许继续，否则直接返回“已抢完”。

原理：DECR是原子操作，避免并发扣减导致的超卖（如两个请求同时读取库存=1，都扣减为0）。

1. Redis 配置（库存缓存与分布式锁）
@Configuration
public class RedisConfig {@Beanpublic RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {RedisTemplate<String, Object> template = new RedisTemplate<>();template.setConnectionFactory(factory);// 序列化配置（避免key乱码）StringRedisSerializer stringSerializer = new StringRedisSerializer();GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer();template.setKeySerializer(stringSerializer);template.setValueSerializer(jsonSerializer);template.setHashKeySerializer(stringSerializer);template.setHashValueSerializer(jsonSerializer);template.afterPropertiesSet();return template;}// 库存缓存Key前缀public static final String SECKILL_STOCK_KEY = "seckill:stock:";// 已处理请求ID缓存Key（防重复提交）public static final String SECKILL_REQUEST_KEY = "seckill:request:";
}

2. 消息队列二次校验

预扣减成功后，请求进入MQ时，携带当前库存快照（如扣减后为999），消费端处理时再次校验Redis库存是否与快照一致（防止Redis数据异常）。

@Configuration
public class RabbitMQConfig {// 秒杀请求队列（用于异步处理库存扣减）public static final String SECKILL_QUEUE = "seckill.queue";// 秒杀交换机public static final String SECKILL_EXCHANGE = "seckill.exchange";// 路由键public static final String SECKILL_ROUTING_KEY = "seckill.routing.key";@Beanpublic Queue seckillQueue() {// 队列持久化，避免消息丢失return QueueBuilder.durable(SECKILL_QUEUE).build();}@Beanpublic DirectExchange seckillExchange() {return ExchangeBuilder.directExchange(SECKILL_EXCHANGE).durable(true).build();}@Beanpublic Binding seckillBinding(Queue seckillQueue, DirectExchange seckillExchange) {return BindingBuilder.bind(seckillQueue).to(seckillExchange).with(SECKILL_ROUTING_KEY);}
}

3. 数据库最终校验与扣减

库存表设计：独立库存表seckill_stock，包含goods_id（商品ID）、remaining（剩余库存）、version（版本号，用于乐观锁）。
乐观锁扣减：消费端处理时，执行SQL：

UPDATE seckill_stock 
SET remaining = remaining - 1, version = version + 1 
WHERE goods_id = 1001 AND remaining > 0 AND version = {当前版本};

若影响行数=1，则扣减成功；否则说明库存不足（已被其他请求扣减），回滚Redis库存（INCR恢复）。

4. 库存兜底校验

活动结束后，对比Redis库存与数据库库存，若不一致（如Redis因网络问题少扣），通过定时任务以数据库为准同步Redis。

四、用户体验优化措施

在保障稳定性的前提下，通过流程简化和状态透明提升用户体验。

1. 抢购流程简化

一步到位：点击“抢购”按钮后，直接完成库存扣减+订单创建，无需跳转多页（减少页面切换耗时）。
默认信息：提前缓存用户收货地址、支付方式，下单时自动填充，减少用户输入。

2. 实时状态反馈

结果页即时展示：无论成功/失败，1秒内返回结果页（成功显示“已抢到，快去支付”，失败显示“手慢了，已抢完”）。
支付倒计时：抢到后显示15分钟支付倒计时，超时自动取消订单并释放库存（避免占库存）。

3. 异常友好提示

网络超时：提示“网络有点卡，正在重试，请稍候”（自动重试1次，避免用户手动操作）。
系统繁忙：提示“当前参与人数过多，我们已为您排队，结果将通过短信通知”（结合MQ异步处理，后续通过短信反馈）。

五、系统交互流程图

1、秒杀核心流程（用户视角）

用户 → 打开秒杀页（预加载商品信息） → 倒计时结束 → 点击“抢购”按钮→ 前端置灰按钮+显示loading → 发送请求到API网关→ 网关限流通过 → 应用服务调用Redis预扣减库存→ 库存不足 → 返回“已抢完” → 前端显示失败页→ 库存充足 → 请求进入MQ → 应用服务异步消费→ MQ二次校验 → 数据库乐观锁扣减库存→ 扣减成功 → 创建订单 → 返回“抢购成功” → 前端显示支付页→ 扣减失败 → 回滚Redis库存 → 返回“手慢了” → 前端显示失败页

2、秒杀服务接口（核心逻辑入口）

@Service
@Slf4j
public class SeckillService {@Autowiredprivate StringRedisTemplate redisTemplate;@Autowiredprivate RabbitTemplate rabbitTemplate;@Autowiredprivate SeckillStockMapper stockMapper;@Autowiredprivate OrderMapper orderMapper;/*** 秒杀核心接口（前端调用入口）* @param userId 用户ID* @param goodsId 商品ID* @param requestId 唯一请求ID（防重复提交）* @return 秒杀结果*/public Result<String> doSeckill(Long userId, Long goodsId, String requestId) {// 1. 防重复提交校验（同一requestId 5分钟内不重复处理）Boolean isExist = redisTemplate.opsForValue().setIfAbsent(RedisConfig.SECKILL_REQUEST_KEY + requestId,"1",5,TimeUnit.MINUTES);if (Boolean.FALSE.equals(isExist)) {return Result.fail("请勿重复提交");}// 2. Redis预扣减库存（原子操作，避免超卖）String stockKey = RedisConfig.SECKILL_STOCK_KEY + goodsId;Long remainingStock = redisTemplate.opsForValue().decrement(stockKey);if (remainingStock == null || remainingStock < 0) {// 库存不足，回滚Redis（因为decrement已减1，需要加回）redisTemplate.opsForValue().increment(stockKey);return Result.fail("手慢了，商品已抢完");}// 3. 发送消息到MQ，异步处理订单创建（削峰填谷）SeckillMessage message = new SeckillMessage(userId, goodsId, requestId, System.currentTimeMillis());try {rabbitTemplate.convertAndSend(RabbitMQConfig.SECKILL_EXCHANGE,RabbitMQConfig.SECKILL_ROUTING_KEY,message);return Result.success("抢购中，请等待结果通知");} catch (Exception e) {// MQ发送失败，回滚库存redisTemplate.opsForValue().increment(stockKey);log.error("MQ发送失败", e);return Result.fail("系统繁忙，请重试");}}
}

3、库存扣减时序图（技术视角）

┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐
│  用户   │     │ 应用服务 │     │  Redis  │     │   MQ    │     │ 数据库  │
└────┬────┘     └────┬────┘     └────┬────┘     └────┬────┘     └────┬────┘│                │                │                │                ││  抢购请求       │                │                │                │├───────────────>│                │                │                ││                │  DECR 库存      │                │                ││                ├───────────────>│                │                ││                │  结果=999       │                │                ││                │<───────────────┤                │                ││                │  发送消息到MQ   │                │                ││                ├───────────────────────────────>│                ││                │  暂返“处理中”   │                │                ││<───────────────┤                │                │                ││                │                │                │  消费消息       ││                │<───────────────────────────────┤                ││                │  校验Redis库存  │                │                ││                ├───────────────>│                │                ││                │  库存=999       │                │                ││                │<───────────────┤                │                ││                │  乐观锁扣减     │                │                ││                ├───────────────────────────────────────────────>││                │  扣减成功       │                │                ││                │<───────────────────────────────────────────────││                │  创建订单       │                │                ││                ├───────────────────────────────────────────────>││  短信通知结果   │                │                │                ││<─────────────────────────────────────────────────────────────────│
┌────┴────┐     ┌────┴────┐     ┌────┴────┐     ┌────┴────┐     ┌────┴────┐
│  用户   │     │ 应用服务 │     │  Redis  │     │   MQ    │     │ 数据库  │
└─────────┘     └─────────┘     └─────────┘     └─────────┘     └─────────┘

六、应急应对措施

异常场景	应对措施
流量远超预期（如20万QPS）	1. 启动紧急限流，将QPS降到8万；2. 临时关闭非核心地区用户访问（如偏远地区）；3. 扩容秒杀服务实例到30台。
Redis集群故障	1. 切换到备用Redis集群；2. 暂时将库存校验逻辑降级到数据库（仅适用于流量已下降场景）。
库存超卖风险（Redis与数据库不一致）	1. 立即暂停活动；2. 以数据库库存为准，回滚Redis和订单；3. 对已超卖订单进行补偿（如发放优惠券）。
用户集中投诉（体验差）	1. 前端弹窗说明“活动火爆，正在优化”；2. 开启“排队队列”，按顺序处理请求并实时更新排队进度。