设计一个支持万人并发抢购的秒杀系统架构方案

2. 高并发请求处理

流量削峰

不要直接打穿数据库，利用消息队列缓冲请求。

@Component
public class SeckillService {
    @Autowired
    private RocketMQTemplate mqTemplate;

    public SeckillResult seckill(SeckillRequest request) {
        if (!validate(request)) {
            return SeckillResult.fail("校验失败");
        }
        String requestId = generateRequestId(request);
        // 请求入队，立即返回
        mqTemplate.sendOneWay("seckill-topic", MessageBuilder.withPayload(request).build());
        return SeckillResult.processing(requestId);
    }
}

分层过滤

请求经过多层漏斗，逐级拦截无效流量。

所有请求 → 合法性校验 → 库存校验 → 频率控制 → 实际下单
100 万   → 50 万       → 10 万     → 5 万      → 1 万

3. 系统性能优化

多级缓存策略

• 一级：JVM 本地缓存 (Caffeine)，存热点商品信息。
• 二级：Redis 集群，存库存信息。
• 三级：数据库，最终一致性来源。

缓存预热

活动开始前加载热点商品到缓存。

@Service
public class CacheWarmUpService {
    @PostConstruct
    public void warmUpSeckillProducts() {
        List<Product> hotProducts = loadHotProducts();
        for (Product product : hotProducts) {
            redisTemplate.opsForValue().set("stock:" + product.getId(), product.getStock());
            redisTemplate.opsForValue().set("product:" + product.getId(), JSON.toJSONString(product));
            bloomFilter.add(product.getId());
        }
    }
}

4. 详细实现方案

秒杀流程

整合上述组件，形成完整链路。

public Response processSeckill(String userId, String productId) {
    // 1. 恶意请求拦截
    if (!checkRisk(userId)) return Response.forbidden("访问过于频繁");
    // 2. 布隆过滤器快速判断
    if (!bloomFilter.contains(productId)) return Response.notFound("商品不存在");
    // 3. 内存标记（已售罄的商品直接返回）
    if (soldOutFlags.get(productId)) return Response.badRequest("已售罄");
    // 4. Redis 原子扣减库存
    if (!deductStockInRedis(productId)) {
        soldOutFlags.put(productId, true);
        return Response.badRequest("库存不足");
    }
    // 5. 生成订单 ID（雪花算法）
    long orderId = snowflake.generate();
    // 6. 订单信息入队
    mq.send(new OrderQueueItem(orderId, userId, productId, System.currentTimeMillis()));
    // 7. 返回排队中
    return Response.ok("排队中", orderId);
}

库存同步方案

后台消费 MQ 消息，异步更新数据库并做对账。

@Component
@Slf4j
public class StockSyncService {
    @Transactional
    public void syncStockToDB(String productId, int count) {
        try {
            boolean success = productDAO.deductStock(productId, count);
            if (success) {
                redisTemplate.opsForValue().set("stock_final:" + productId, getDBStock(productId));
                soldOutCache.remove(productId);
            }
        } catch (Exception e) {
            log.error("库存同步失败", e);
            alertService.sendAlert(e);
        }
    }

    @Scheduled(cron = "0 */5 * * * ?")
    public void stockReconciliation() {
        List<Product> products = productDAO.getAllSeckillProducts();
        for (Product product : products) {
            Integer redisStock = getRedisStock(product.getId());
            Integer dbStock = product.getStock();
            if (!Objects.equals(redisStock, dbStock)) {
                log.warn("库存不一致：productId={}, redis={}, db={}", product.getId(), redisStock, dbStock);
                fixStockInconsistency(product.getId(), dbStock);
            }
        }
    }
}

三、高可用保障

1. 限流降级策略

多维度配置限流规则，防止雪崩。

• 用户维度：每个用户 10 次/分钟
• IP 维度：每个 IP 1000 次/分钟
• 商品维度：每个商品 10000 次/分钟
• 总 QPS：系统最大承受 50000 QPS

2. 熔断降级

使用 Hystrix 等组件保护后端服务。

@RestController
public class SeckillController {
    @GetMapping("/seckill/{productId}")
    @HystrixCommand(
        fallbackMethod = "seckillFallback",
        commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"),
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20")
        }
    )
    public Response seckill(@PathVariable String productId, @RequestParam String userId) {
        return seckillService.process(userId, productId);
    }

    public Response seckillFallback(String productId, String userId) {
        return Response.error("系统繁忙，请稍后重试");
    }
}

四、监控与告警

关键监控指标

• 系统层面：QPS、RT、错误率、CPU/内存使用率。
• 应用层面：库存扣减成功率、消息堆积量。
• 业务层面：抢购成功率、用户排队时长。

监控实现

@Component
public class SeckillMonitor {
    private final MeterRegistry meterRegistry;

    public void recordSeckill(String productId, boolean success, long cost) {
        meterRegistry.counter("seckill.requests.total").increment();
        if (success) {
            meterRegistry.counter("seckill.success.total").increment();
        } else {
            meterRegistry.counter("seckill.fail.total").increment();
        }
        meterRegistry.timer("seckill.process.time").record(cost, TimeUnit.MILLISECONDS);
        meterRegistry.gauge("seckill.stock." + productId, getCurrentStock(productId));
    }
}

五、部署与扩展

弹性扩展策略

• 水平扩展：无状态服务可快速扩容。
• 自动伸缩：基于 CPU 使用率或 QPS 自动扩缩容。
• 异地多活：重要业务支持多机房部署。

压测方案

• 场景 1：库存预热，10 万用户同时抢 1 万商品。
• 场景 2：持续高压，5 万 QPS 持续 5 分钟。
• 场景 3：峰值冲击，瞬间 20 万 QPS。
• 目标：成功率 >99.9%，平均 RT <100ms，错误率 <0.1%。

六、安全考虑

• 防刷机制：验证码（峰值时降级）、设备指纹、行为分析。
• 数据安全：关键数据加密、操作日志记录、防篡改校验。

总结要点

1. 架构核心：分层过滤 + 异步处理 + 最终一致。
2. 库存核心：Redis 原子操作 + 消息队列 + 数据库乐观锁。
3. 性能核心：缓存预热 + 流量削峰 + 读写分离。
4. 稳定核心：熔断降级 + 限流隔离 + 快速失败。

面试回答建议

在面试中阐述秒杀系统设计时，建议围绕以下逻辑展开：

首先，架构设计上要动静分离、分层削峰。我会把系统分为静态资源分离、网关层限流、业务逻辑后置以及服务独立部署。特别是秒杀的核心——'下单扣库存'这个最重要的逻辑，绝不放在前台实时处理。用户点击'抢购'后，前端直接返回'排队中'，请求进入消息队列。这样一来，海量并发就被平滑成顺序处理的流量，后端服务按照自己的能力从队列里慢慢消费，实现削峰填谷。

其次，针对如何解决超卖、库存扣减和高并发请求这三个核心问题，我的解决方案是：

• 解决超卖和库存扣减：这是秒杀的核心。我的方案是预扣库存，活动开始前把商品的库存从主库加载到 Redis 中。Redis 是单线程内存操作，可以保证原子性。在 Redis 里，使用 DECR 或 LUA 脚本来扣减库存。LUA 脚本可以打包多个操作（检查库存、扣减），确保整个过程原子性，彻底杜绝超卖。后台服务从队列消费，成功扣减 Redis 库存后，生成一个订单 ID，再异步去更新数据库的库存。
• 应对高并发请求：除了网关层的总限流，在秒杀服务本身也要做限流，比如用信号量或令牌桶控制处理线程数。秒杀服务做成无状态的，方便用 K8s 或云服务快速横向扩容。对于'爆款'商品，它的库存 Key 在 Redis 里是热点 Key，可以做 Key 散列，把压力分散到多个 Redis 节点。

最后，还有一些关键的细节和兜底策略：

• 防刷与验证：前端加入计算型验证码或答题，防止机器人；下单前必须校验用户资格。
• 异步下单与结果轮询：用户提交后，服务端返回一个'排队 ID'，前端用这个 ID 轮询后端，查询最终结果。
• 数据一致性对账：因为用了 Redis 和消息队列，可能出现极端情况下的数据不一致。需要有一个定时对账任务，核对 Redis、数据库库存和订单状态，进行修复。
• 降级与熔断：如果 Redis 或数据库访问慢，要有熔断机制，防止服务被拖垮。

总结一下，我的设计思路是：前端限流拦截，请求队列削峰；Redis 原子扣减防超卖；服务无状态化应对高并发；再通过异步、对账等手段保证最终一致性和用户体验。