秒杀系统

参考：https://blog.csdn.net/github_37048196/article/details/83573935

          http://blog.51cto.com/13515764/2309588?source=dra

一、概念

秒杀，通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动。

二、秒杀的特点

1.瞬时并发量大
秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。
2.库存量少
 一般秒杀活动商品量都很少，这就导致了只有极少量用户能成功购买到商品。
3.业务简单
流程相对比较简单，一般都是下订单、扣库存、支付订单

三、技术挑战

1.对原有业务形成冲击
秒杀活动只是网站营销的一个附加活动，特点是：时间短、并发访问量大，如果和网站原有应用部署在一起，必然会对现有业务造成冲击。
解决方案：将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。

2.高并发下数据库、应用负载
用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。
解决方案：重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化，用户请求不需要经过应用服务

3. 突然增大的服务器和网络带宽
假设商品页面大小200K，10000个请求的带宽就是2G。
解决方案：因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存到CDN

4. 防止秒杀前下单
秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。
解决方案：为了避免用户直接访问下单页面URL，需要将改URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。

四、架构设计思想

限流
        限制大部分用户流量，只准许少量用户流量进入后端服务器
削峰
        秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。一般采用缓存和 MQ 中间件来解决
异步
       考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性
缓存
       把部分业务逻辑迁移到内存缓存或者 Redis 中，提高并发效率

五、整体架构

 

客户端优化

1.秒杀页面
把秒杀页面整体进行静态化，并将页面静态化之后的页面分发到 CDN 边缘节点上，起到压力分散的作用。

2.防止提前下单
在静态化页面中加入一个很小的 JS 文件引用，文件包含活动是否开始的标记以及开始时的动态下单页面的URL参数。当活动快开始的时候（比如提前），通过后台接口修改这个 JS 文件使之生效

API 接入层优化
1.限制用户维度访问频率
针对同一个用户（Userid 维度），做页面级别缓存，单位时间内的请求，统一走缓存，返回同一个页面
2.限制商品维度访问频率
大量请求同时间段查询同一个商品时，可以做页面级别缓存，不管下回是谁来访问，只要是这个页面就直接返回

服务层优化
对于后端系统的控制可以通过消息队列、异步处理、提高并发等方式解决。对于超过系统水位线的请求，直接采取 「Fail-Fast」原则，拒绝掉

 

六、整体流程图

     

七、总结

       核心思想：层层过滤，逐渐递减瞬时访问压力

       尽量将请求拦截在上游，降低下游的压力

       充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用