秒杀场景的业务和技术难点分析

秒杀场景的业务和技术难点分析开始：

一、秒杀业务需求分析

1、秒杀发生的时间节点 一般都是在新品上市，促销的时候：价格低廉

2、秒杀的目的 通过发布一定数量的秒杀商品达到促进销售的目的，吸引用户关注：大幅推广

3、秒杀的特点 秒杀是一个典型的读多写少的业务，大量用户参与秒杀，真正能抢到商品的微乎其微，所以大部分的用户只是浏览查看到了商品并没有抢购成功：瞬时售空

4、秒杀的流程 秒杀流程一定要短：定时上架，瞬时并发高

二、秒杀技术难点及解决方案：

1、对现有网站业务造成冲击秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。

解决方案：将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。

2、高并发下的应用、数据库负载用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。

解决方案：重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化，用户请求不需要经过应用服务。

3、突然增加的网络及服务器带宽假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。

解决方案：因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。

三、秒杀上游设计图：CDN架构

四、秒杀架构原则和设计

原则：

1、尽量将请求拦截在系统上游，传统秒杀系统之所以挂，请求都压到了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】。

2、读多写少的场景多使用缓存这是一个典型的读多写少的应用场景【一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适合使用缓存。

设计：

1、秒杀系统为秒杀而设计，不同于一般的网购行为，参与秒杀活动的用户更关心的是如何能快速刷新商品页面，在秒杀开始的时候抢先进入下单页面，而不是商品详情，因此秒杀系统的页面设计应尽可能简单

2、下单表单也尽可能简单，购买数量只能是一个且不可以修改，送货地址和付款方式都使用用户默认设置，没有默认也可以不填，允许等订单提交后修改；只有第一个提交的订单发送给网站的订单子系统，其余用户提交订单后只能看到秒杀结束页面

 五、秒杀前端设计

1、秒杀要开始时用户一般都会不断刷新界面 静态界面加载js、css、图片都是需要占用带宽的，几千万人参与一个商品的抢购，可能会需要十几G的网络带宽。 解决方案：静态资源存放到各CDN节点，把静态资源缓存到各CDN节点，用户可以就近访问，加快访问速度。

2、用户点击秒杀后，按钮置灰。

3、js限制x秒内只能提交一次。
     这些前端限制是非常有必要的，基本上可以拦截99%的请求。

六、秒杀站点设计

普通程序员玩家查看你界面请求直接请求站点怎么办？

1、nginx层做针对同一ip的访问频率限流。

2、同一查询在站点层限制访问频率。

3、如果高端程序员玩家手里掌握了10W台肉鸡服务器，怎么办？ 

    做验证码校验，有些网站需要做实名认证。

     这样又可以拦截99%流量在站点层。

七、秒杀服务层设计

服务层核心设计思想，尽量把大量的请求不要瞬时落到数据库层

1、读请求，cache来扛，memcached，redis单机扛10W+应该没问题。

2、写请求，用队列，由并行转串行，每次只放有限的写请求去数据库，成功了再放下一批。

     如此只有非常少的请求能落到数据库，又有99.9%的请求被拦住了

八、秒杀数据库设计

九、高并发下吞吐量和系统保护

QPS的计算

秒杀接口的设计指标为：5W/S的QPS

例如秒杀系统有20台web服务器，MaxClients为500，处理业务的平均响应时间为100ms。

那么，web系统的理论峰值QPS为 20*500/0.1 = 100000  10W/S QPS

这是绝对理论情况

MaxClients的配置指标？

MaxClients是web服务器配置的连接数，是一个线程数，但是并不是线程数越多就越好，为什么呢？ 因为线程多了会增加CPU、内存的计算压力，线程切换是比较耗时的，线程的切换势必会增加用户的响应时间。所以web服务器的连接数要根据CPU、内存等硬件的实际情况来设置。

假如5W/S的并发怼过来，实际发现平均响应时间是250ms

计算系统QPS：20*500/0.25 = 40000  4W/S QPS

那么这里就存在一个问题，有1W的请求没办法处理，怎么办？？会带来什么问题？？

这就是类似于大堵车，本来就有5条道，现在一条道发生车祸只剩4条道了，那么势必就会堵车。 同理，理论最大并发只有4W，现在来了5W势必既有1W个请求没办法处理。会出现请求拒绝的情况。

其实在正常非高并发的请求里面，也有类似的问题存在，业务请求接口异常响应极慢，久而久之就会把整个服务器的可用连接数占满了，然而越是这种情况，越是系统不可用用户点击越频繁，这台服务器有问题，分流软件把流量导到其他服务器，导致其他服务器也崩溃，将整个web系统拖垮，产生服务雪崩。

流量过大处理不过来的时候，就必须要有过载保护机制

例如秒杀场景，流量往往大到跟我们当初设计的不在一个量级，如果出现这种情况，可以将流量拦截在站点层，比如在nginx层面就拦截掉，尽量不要把灾难引到服务层。

十、系统安全的矛和盾

秒杀和抢购收到了“海量”的请求，实际上里面的水分是很大的。不少用户，为了“抢“到商品，会使用“刷票工具”等类型的辅助工具，帮助他们发送尽可能多的请求到服务器。还有一部分高级用户，制作强大的自动请求脚本。这种做法的理由也很简单，就是在参与秒杀和抢购的请求中，自己的请求数目占比越多，成功的概率越高

1、同一账号发送多次请求

这种加锁就可以解决，redis锁，如果其中一个请求获取锁成功就允许秒杀，其他都拒绝

2、多个账号发送多次请求

黄牛党，僵尸号在秒杀开始的时候疯狂请求 可以做ip限制，如果某个ip请求频率过高，可以弹验证码或者实名验证，其实就是判断是否是活人。

3、多个账号，不同ip

这种就比较复杂了，典型的就是高级黑客手里掌握了N多肉鸡服务器，那么ip就不一样了。

这种请求就跟普通用户请求基本上类似了。

这种必须要做业务限制，提高秒杀的参与门槛，比如只有星级用户、账号等级等等业务手段来做限制。而僵尸账号往往账号等级和活跃度都不高。

到此，秒杀场景的业务和技术难点分析完毕，下篇我们通过代码的形式去实现秒杀功能，敬请期待！