这一次，618 JD.COM实现订单金额2692亿元。你贡献了多少股份？

5月25日至5月31日进入预热阶段，6月1日至6月15日进入特殊阶段，6月16日至6月18日进入高潮阶段，6月18日至6月20日进入回归阶段。每个阶段都有自己的玩法，优惠券、红包、满减、限量秒杀，让你心甘情愿地掏出钱包。

其中最吸引人的是“限时秒杀”，因为参与限时秒杀的商品价格都很便宜，商家和平台会在上架前宣传很多，而且只在某个时间点上架。因为以上三个特点，会指定大量用户参与限时秒杀活动，从而导致系统瞬时并发的增加。

还记得2013年的小米秒杀活动吗？三款小米手机每款卖11万台，3分钟售罄，每秒近60万次请求。支持这种即时请求突发的系统是spike系统。今天就给大家揭秘大促背后的秒杀系统是怎么设计的~

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

我们需要把秒杀系统设计成一个独立的电子商务系统，包括业务系统、网络带宽、运维部署等。

秒杀系统的商业规则是，要等到秒杀时间才能下单购买商品。在那段时间之前，你只能浏览产品信息，不能下单。因为秒杀产品，比如小米手机，iPhone，空 tone，春运抢火车票等产品很难抢购到，必然有黄牛，抢票软件等等不断提出请求，甚至有专家可以通过编写自动化脚本来获得产品。

所以无论是秒杀系统的前端设计还是后端设计，都需要考虑到这几点。

从前端设计来看，秒杀购买的按钮只有在秒杀来的时候才能点击。在秒杀到来之前，必须有用户不断刷新页面。这一幕想必朋友们都很熟悉。618、双11、春运抢放票前，他们不断用手机、电脑刷新页面。

每次刷新都会给服务器带来负载压力，所以这个页面设计为静态页面，缓存在CDN、用户浏览器和反向代理服务器中。购买按钮是否被点击是由js脚本动态控制的。

从后端设计来看，在秒杀活动开始的时候，必然会有大量的请求进来，需要通过限流、消息排队等手段来保证服务的正常运行。

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

其次，通过使用MQ消息中间件，将用户的所有请求放入队列中，通过设置队列的最大阈值(即商品的最大库存数)，可以保证用户能够正常请求服务。消息队列将商品系统和库存系统分为两部分，使得订货和减库存操作互不强制依赖，保证了用户体验。

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

从网络设计的角度来说，由于一个产品的html页面包含了产品描述、产品图片等信息，再加上css、js脚本等资源，大概有几百K(我们假设600K)。如果10000人同时参加一个产品的抢购，需要的网络带宽大概是6g(600K * 10000)，这个带宽的增加是秒杀活动造成的，平时用不了这么多。

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

从参与者的公平性来看，因为秒杀活动便宜不贵，除了用户本身，还有大量抢票软件和黄牛抢购。为了保证活动的公平性，我们可以将其设计在浏览器和服务器中。

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

以前我们都是以参与者的身份参与商品的秒杀活动，在618、双十一这样的大促销中贡献订单金额。现在，尤其是今天介绍完秒杀系统的设计之后，更应该从技术人员的角度来看待全民狂欢。订单量的每一次增长，背后都是技术的又一次突破。18已经过去了，双十一也快到了。让我们一起期待上亿订单的突破和背后的又一次技术升级吧~