糟糕，老板让我设计一个亿级用户秒杀系统！

这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成静态页面并上传到 CDN 预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到 Redis，避免秒杀开始后大量的缓存穿透。

部署隔离

秒杀相关服务和日常服务要分组部署，不能因为秒杀出问题影响日常售卖业务。

可以申请单独的秒杀域名，从网络入口层就开始分流。网关也单独部署，秒杀走自己单独的网关，从而避免日常网关受到影响。

秒杀可以复用订单，库存，支付等日常服务，只是需要一些小的改造(比如下单流程走消息队列，批量写入订单库，以及在 Redis 中扣减库存)。

数据隔离

为了避免秒杀活动影响到日常售卖业务，Redis 缓存需要单独部署，甚至数据库也需要单独部署!数据隔离后，秒杀剩余的库存怎么办?

秒杀活动结束后，剩余库存可以归还到日常库存继续做为普通商品售卖。数据隔离后，秒杀订单和日常订单不在相同的数据库，之后的订单查询怎么展示?

可以在创建秒杀订单后发消息到消息队列，日常订单服务采取拉的方式消费消息。

这时日常订单服务是主动方，可以采用线程池的方式，根据机器的性能来增加或缩小线程池的大小，控制拉取消息的速度，来控制订单数据库的写入压力。

网络

秒杀前要和网络运营商、CDN 服务商提前申请带宽。

还有哪些细节要考虑：

①如何避免超卖?如果在 Redis 中扣减库存，可以利用 decr 命令扣减库存，decr 是原子操作，在分布式环境下也不会有并发问题，decr 扣减库存后，判断返回值，如果返回值小于 0，扣减库存失败，秒杀也就失败了。

如果在数据库中扣减库存可以在 where 后面加上库存大于 0 的条件，来避免库存被减成负值。这样就可以避免超卖情况发生了。

②接口防刷，前面已经提到过，在网关层对下单等接口按 userID 限流。

③网关层除了对 userID 做限流外，还要做整体限流。在实际访问量超过预估访问量时，整体限流可以起到保护作用，避免系统被压垮。

④防止重复下单，按 userID 限流已经起到了防止重复下单的作用。假如限制同一个用户 10 分钟能下一次单，一般情况下 10 分钟内，商品早已经被抢光了，用户也就没有再次下单的机会了。

⑤可以结合风控系统，在网关层把羊毛党等有问题的用户请求直接拒掉。

⑥可以在网关层上面再加一层防火墙或者高防服务，来防御 DDos 等分布式网络攻击。