一、单独的服务、数据库
秒杀是瞬时流量超高的业务,为了避免影响到原本正常的功能,因此需要单独的秒杀服务、数据库。
二、Nginx负载均衡
Nginx是高性能的web服务器,一般能承受几万QPS的并发,而单个Tomcat一般只能承受几百QPS的并发,因此可以部署多个秒杀服务,通过Nginx做负载均衡,分发并发流量。
三、限流
前端限流:
- 秒杀没开始前,按钮置灰,秒杀时间到了,才能点击。
- 用户点击之后,再置灰几秒,不能一直点击。
后端限流:
- Sentinel、Hystrix等限流组件。
- 令牌通限流。
- 针对用户、IP限制频率。
另外还需要降低、熔断、隔离。
四、前端资源静态化
将商品的描述、参数、成交记录、图像、评价等全部写入到一个静态页面,用户请求不需要通过访问后端服务器,不需要经过数据库,直接在前台客户端生成,再把静态部署到CDN服务器,这样可以最大可能的减少服务器的压力。
五、秒杀链接加盐
链接暴露会使黄牛党不通过页面,直接用工具或者脚本抢单,就算加上时间校验,也有可能在开始秒杀瞬间抢到大量订单,所以秒杀链接很重要,不能暴露。
URL动态化,在后端通过MD5等方式加密,让前端动态获取这个链接,请求的时候后端校验。
六、超卖问题
秒杀场景要特别注意超卖问题,卖多了可能会使商家亏本。
- 使用分布式锁实现
- 使用乐观锁实现,如:
update t_product set stock = stock - #{num} where id = #{id} and stock >= #{num}
但这种方案会使大量请求直接打到数据库。
七、库存预热
在秒杀开始之前,提前把商品库存加载在Redis中,通过Lua脚本实现扣减库存的逻辑。判断当剩余数量 >= 购买数量时,扣除库存,返回1;当剩余数量 < 购买数量时,返回false。
再异步慢慢同步库存回数据库即可。
八、Redis高可用
秒杀是读多写少场景,可通过哨兵机制、Redis集群、主从同步、读写分离实现高可用,同时要注意防止缓存穿透、缓存击穿等问题。
九、异步下单,流量削峰
秒杀时直接生成订单落库,在高并发场景下,会给数据库很大压力。
可以在抢到库存后,把下单信息放到MQ中,这时返回前端秒杀成功,并跳转支付页面。
订单消费者监听MQ,异步生成订单落库,达到流量削峰的目的。
此时需要注意MQ消息可靠性和幂等性问题。
十、风控
针对专业黑客、黄牛团队,可以通过风控判断出这部分用户直接禁止下单。