秒杀活动设计

一、单独的服务、数据库

秒杀是瞬时流量超高的业务，为了避免影响到原本正常的功能，因此需要单独的秒杀服务、数据库。

二、Nginx负载均衡

Nginx是高性能的web服务器，一般能承受几万QPS的并发，而单个Tomcat一般只能承受几百QPS的并发，因此可以部署多个秒杀服务，通过Nginx做负载均衡，分发并发流量。

三、限流

前端限流：

1. 秒杀没开始前，按钮置灰，秒杀时间到了，才能点击。
2. 用户点击之后，再置灰几秒，不能一直点击。

后端限流：

1. Sentinel、Hystrix等限流组件。
2. 令牌通限流。
3. 针对用户、IP限制频率。

另外还需要降低、熔断、隔离。

四、前端资源静态化

将商品的描述、参数、成交记录、图像、评价等全部写入到一个静态页面，用户请求不需要通过访问后端服务器，不需要经过数据库，直接在前台客户端生成，再把静态部署到CDN服务器，这样可以最大可能的减少服务器的压力。

五、秒杀链接加盐

链接暴露会使黄牛党不通过页面，直接用工具或者脚本抢单，就算加上时间校验，也有可能在开始秒杀瞬间抢到大量订单，所以秒杀链接很重要，不能暴露。

URL动态化，在后端通过MD5等方式加密，让前端动态获取这个链接，请求的时候后端校验。

六、超卖问题

秒杀场景要特别注意超卖问题，卖多了可能会使商家亏本。

1. 使用分布式锁实现
2. 使用乐观锁实现，如：
   update t_product set stock = stock - #{num} where id = #{id} and stock >= #{num}

但这种方案会使大量请求直接打到数据库。

七、库存预热

在秒杀开始之前，提前把商品库存加载在Redis中，通过Lua脚本实现扣减库存的逻辑。判断当剩余数量 >= 购买数量时，扣除库存，返回1；当剩余数量 < 购买数量时，返回false。

再异步慢慢同步库存回数据库即可。

八、Redis高可用

秒杀是读多写少场景，可通过哨兵机制、Redis集群、主从同步、读写分离实现高可用，同时要注意防止缓存穿透、缓存击穿等问题。

九、异步下单，流量削峰

秒杀时直接生成订单落库，在高并发场景下，会给数据库很大压力。

可以在抢到库存后，把下单信息放到MQ中，这时返回前端秒杀成功，并跳转支付页面。

订单消费者监听MQ，异步生成订单落库，达到流量削峰的目的。

此时需要注意MQ消息可靠性和幂等性问题。

十、风控

针对专业黑客、黄牛团队，可以通过风控判断出这部分用户直接禁止下单。