秒杀系统架构如何设计之我见

秒杀背景

电商中为了吸引顾客、汇集人气，常常会策划一些秒杀活动。活动中售卖的商品，要么价格远低于市场价格，要么比较稀缺（如一些新发布的商品）。这些商品电商通常都会限量、限时销售。无疑这些商品对消费者的诱惑力是巨大的，消费者蜂拥而来，每每几秒钟就能够将商品抢购一空。而对于电商系统来讲可能更多的是考验。

秒杀痛点

首先，秒杀的场景决定了秒杀是一场速度的比拼，也就是俗话说的“手快有、手慢无”。你们都争着在活动开始后，第一时间将商品抢到，完成下单。所以秒杀活动开始的一瞬间会有大量的流量涌入，几倍、甚至于十几倍的流量对系统的冲击不可谓不大。若是系统没有足够的capacity或应对措施，极可能就被瞬时高流量给压垮了。

其次，突如其来的高流量，给系统各个模块都来了一连串的压力，系统可能会所以变慢，并且可能会彼此影响，影响可用性。好比：数据库更新同一个商品库存，需对同一行记录加锁，随着并发的压力逐渐增大，数据库更新的性能是逐渐降低的。从而引发提供库存service的应用服务性能降低，连锁的影响到下单service的性能，最终反馈到消费者的可能就是整个网站购物流程性能差、响应慢。而面对响应慢的系统，不少消费者可能采起反复刷新，屡次尝试，这无疑又增大了对系统的压力。

还有，上述种种给消费者带来的每每是体验上的痛苦。如：网站响应慢，点击抢购按钮没反应。好不容易能够操做了，却发现秒杀活动已经结束，消费者的参与感比较差。长此以往，可能就对此类活动失去了兴趣。

设计理念

分层限流：将压力尽可能集中在前端，减小数据库、服务器的压力
异步处理：异步处理防止阻塞。
可用性：高可用双活。
用户体验：隐藏购买地址。
分离：主站分离。

技术攻关

短期内的大访问量对现有网站业务形成的冲击。

秒杀是一个网站营销的一个附加活动，时间短，并发量大。

若是和网站原有应用部署在一块儿，必然会对现有业务形成冲击，稍有不慎可能致使整个网站瘫痪。

高并发下对服务器数据库形成的极大负载压力。

用户秒杀开始前，经过不断刷新浏览器来保证不会错过秒杀活动。

频繁的访问程序、数据库会对应用服务器和数据库服务器形成负载压力。

网络带宽的问题比超过平时好多倍。

若是秒杀页面的大小为200K，若是最大并发数为10000次，那么须要的网络和服务器带宽是2G（200K×10000）。

这些网络带宽是由于秒杀活动新增的，超过网站平时使用的带宽。

避免直接下单。

秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点以前，只能浏览信息不可下单。

而下单页面也是一个普通的URL，若是获得这个URL，不用等到秒杀开始就能够下单了。

应对策略

秒杀系统独立部署

为了不短期内的大访问量对现有网站业务形成的冲击，能够将秒杀系统独立部署。

若是须要还可使用独立域名，使其与网站彻底隔离。

即便秒杀系统崩溃了，也不会对网站形成影响。

秒杀商品页面静态化

将商品描述、参数、详情，所有写到一个静态页面，不用进行程序的逻辑处理，不需访问数据库。

不用部署动态的服务器和数据库服务器。

租借秒杀活动的网络带宽

由于秒杀新增的网络带宽，必须和运营商从新购买或租借带宽。

为了减轻服务器的压力，须要将秒杀商品页面缓存在CDN,一样CDN服务器也须要临时租借带宽。

动态生成随机下单页面的URL

为了不用户直接访问下单URL,须要将URL动态化，用随机数做为参数，只能秒杀开始的时候才生成。

架构设计

如何控制秒杀商品页面抢购按钮的可用/禁用。

购买按钮只有在秒杀开始的时候才能点亮，在此以前是灰色的，显示活动未开始。

若是页面是动态生成的，每次刷新都要请求服务器，那么势必形成服务端的负载压力。

若是页面是静态页面的话，能够将页面缓存在CDN，反向代理服务器上，甚至用户浏览器上。

可是这样，秒杀开始时，用户刷新页面，根本请求不到应用服务器。

解决方案：

使用JS脚本控制，在页面中引用一个JS文件(文件极小)，可是该文件不要被缓存。

该JS的做用是，包含秒杀开始标志，修改样式，生成下单页面的URL及随机参数。

该JS文件不被缓存的作法：xxx.js?v=随机数。

会有一台服务器进行监控(定时上下架)：

当秒杀活动开始时推送该文件。

当秒杀活动结束时推送文件，标示结束标志，修改样式。

详情：2018-01-27 20:00 实战构建PHP千万级PV秒杀系统 讲堂