“618”背后的秒杀系统如何设计？

这次618京东实现下单金额2692亿元，你贡献了多少份额呢？

 

从5月25日-5月31日进入预热阶段，6月1日-6月15日进入专场阶段，6月16日-6月18日进入高潮阶段，6月18日-6月20日进入返场阶段，每个阶段都有每个阶段的玩法，优惠券、红包、满减、限时秒杀，让你心甘情愿的掏出钱包还乐乐呵呵。

 

而这其中最具吸引力的便是“限时秒杀”了，因为参加限时秒杀的商品，价格非常的便宜，在上架之前商家和平台都会进行大量的宣传，并且只在某个时间点上架，由于上述三个特征有大量的用户定点来参加限时秒杀活动，这导致瞬间系统并发量会增加。

 

还记得2013年的小米秒杀活动吗？三款小米手机各11万台开卖，3分钟就售光，每秒接近60万个请求，而支撑如此瞬间爆发海量请求的系统便是秒杀系统了，而今天我们就给大家揭秘大促背后的秒杀系统如何进行设计～

 

商品秒杀本质上也是一种运营活动，通过低廉的价格吸引大量用户，打造品牌，为店铺引流，所以秒杀商品的整个流程自然也包括商品信息展示、用户查询商品、用户购买商品创建订单、系统扣减库存、系统更新订单信息、用户付款、商家发货了。

 

我们需要把秒杀系统当成一套独立的电子商务系统进行设计，设计内容包含业务系统、网络带宽、运维部署等部分。

 

秒杀系统的业务规则是到了秒杀时间才能对商品进行下单购买，在该时间点之前只能浏览商品信息，不能下单。而因为秒杀商品，比如小米手机、iPhone、空调、春运火车票等商品都属于很难抢购，所以必定有黄牛、抢票软件等不断的去发起请求，甚至会有高手通过写自动化脚本获取商品。

 

所以在秒杀系统的前端设计和后端设计都需要把这些点考虑进来。

 

从前端设计来说，秒杀商品购买的按钮只有等到秒杀时才可以点击，在秒杀到来的那一刻之前，必定有用户不断的刷新页面，这一幕想必小伙伴们一定很熟悉吧，618、双11、春运放票之前不断的用手机、电脑刷新页面。

 

每次刷新都会给服务器端带来负载压力，因此将该页面设计成静态页面，缓存在CDN、用户浏览器、反向代理服务器上。对于购买按钮的点击与否通过js脚本来动态控制。

 

从后端设计来说，秒杀活动一开始，必定涌来大量的请求，需要通过限流、消息队列等手段保障服务可正常运行。

 

首先通过服务的集群部署，使用负载均衡工具（如Nginx）将用户请求分发到不同的机器上，能一定程度缓解服务器压力。

 

其次通过使用MQ消息中间件将用户请求全放在队列里，通过设置队列的最大阈值（即商品的最大库存数）可以保障用户都能正常请求服务，消息队列把商品系统和库存系统分为了两部分，使得下单、减库存操作互相不强制依赖从而保障了用户的使用体验。

 

最后将成功进入消息队列的请求封装成事务提交给数据库，由数据库进行处理即可。

 

从网络设计上来说，因为商品的html页面包含了商品描述、商品图片等信息，再加上css、js脚本等资源，大概有几百K（我们假设600K），如果同时10000人参与一个商品的抢购，需要的网络带宽大约是6G（600K*10000），而这些带宽的增加是因为秒杀活动带来的，平时使用不了这么多，比较好的方式就是和运营商临时租借。

 

从服务部署来说，因为秒杀活动时间短、高并发的特点，为了避免对整个网站造成冲击、带来瘫痪，一般采用独立部署，使其与网站单独隔离。

 

从参与者公平的角度来说，因为秒杀活动物美价廉量少，除了用户自己在抢之外，还有大量的抢票软件、黄牛在进行抢购，为了保障活动的公平性，我们可在浏览器和服务端进行设计。

 

在浏览器端，通过JS脚本限制用户在N秒内只能提交一次请求，点击了查询或购买按钮之后，不能再次点击。在服务器端，对于同一个ID，限制访问的频率，N秒内到达后端的请求只返回同一页面，同一个商品的查询，N秒内到达的只返回同一个页面。通过技术手段的限制，即使是高手也不能囤积大量的货物。

 

以前，我们都是作为参与者参加商品的秒杀活动，在618、双十一这样的大促里贡献订单额，而现在，特别是在今天介绍了秒杀系统的设计后，我们更应该以技术人的角度去看全民狂欢节，每一次订单额的上升背后都是技术上又一次突破啊。618已经过去了，双十一即将到来，我们且期待着此次的订单额又是多少亿的突破以及背后的又一次技术升级吧～