CSDN双十一的秒杀场景是如何设计的？

本文插图
秒杀这个话题到现在来说已经是一个老生常谈的话题了，不过因为又临近一年一度的双11 ，而且发现前段时间无论是阿里还是腾讯一些大厂其实还是在频繁的问到这个场景题，所以还是准备拿出来说说。秒杀从规模上来说可以分为大秒和小秒。大秒指的是比如双11这种特定的节日，商品规模超大、价格超低、流量超大的这种类型活动，小秒一般指的是商家自己配置的一些时段类型的活动，由商家自己指定时间上架。从形式来说还可以分为单时段秒杀和多时段秒杀。但是在这个场景里，我们一般就是指的单时段大型秒杀。秒杀设计要面对的压力和难度有几点：

怎么保证超高的流量和并发下系统的稳定性？如果峰值的QPS达到几十万，面对巨大的流量的压力系统怎么设计保证不被打崩？
怎么保证数据最终一致性？比如库存不能超卖，超卖了那亏本的要么就是商家要么就是平台，用户反正不背这个锅，超卖了就今年325预订。

当然，涉及到这种大型的活动，还需要考虑到数据统计分析，总不能活动做完了，效果不知道怎么样。系统架构假设今年的双11预估峰值QPS将会有50万(我随便扯的) ，而根据我们平时的经验单机8C8G的机器可以达到1000左右的QPS ，那么从理论上来说我们只要500台机器就可以抗住了，就有钱任性不行？这么设计的话只能出门右转不送了。一、流量过滤本质上，参与秒杀的用户很多，但是商品的数量是有限的，真正能抢到的用户并不多，那么第一步就是要过滤掉大部分无效的流量。

活动开始前前端页面的Button置灰，防止活动未开始无效的点击产生流量
前端添加验证码或者答题，防止瞬间产生超高的流量，可以很好的起到错峰的效果，现在的验证码花样繁多，题库有的还要做个小学题，而且题库更新频繁，想暴力破解怕是很难。当然我知道的还有一种人工打码的方式，不过这个也是需要时间的，不像机器无限刷你的接口。
活动校验，既然是活动，那么活动的参与用户，参加条件，用户白名单之类的要首先做一层校验拦截，还有其他的比如用户终端、IP地址、参与活动次数、黑名单用户的校验。比如活动主要针对APP端的用户校验，那么根据参数其他端的用户将被拦截，针对IP、mac地址、设备ID和用户ID可以对用户参与活动的次数做校验，黑名单根据平时的活动经验拦截掉一部分羊毛党等异常用户。
非法请求拦截，做了以上拦截如果还有用户能绕过限制，那不得不说太牛X了。比如双11零点开始还做了答题限制，那么正常人怎么也需要1秒的时间来答题吧，就算单身30年手速我想也不能超过0.5秒了，那么针对刚好0点或者在0.5秒以内的请求就可以完全拦截掉。
限流，假设秒杀10000件商品，我们有10台服务器，单机的QPS在1000 ，那么理论上1秒就可以抢完，针对微服务就可以做限流配置，避免后续无效的流量打到数据库造成不必要的压力。针对限流还有另外一种栅栏方式限流，这是一种纯靠运气的限流方式，就是在系统约定的请求开始的时间内随机偏移一段时间，针对每个请求的偏移量不同，如果在偏移时间之内就会被拦截，反之通过。

二、性能优化【CSDN双十一的秒杀场景是如何设计的？】做完无效流量的过滤，那么可能你的无效请求已经过滤掉了90% ，剩下的有效流量会大大的降低系统的压力。之后就是需要针对系统的性能做出优化了。