秒杀系统架构要素

秒杀是电子商务网站常见的一种营销手段。

原则

不要整个系统宕机。
即使系统故障，也不要将错误数据展示出来。
尽量保持公平公正。

实现效果

秒杀开始前，抢购按钮为活动未开始。
秒杀开始时，抢购按钮可以点击下单。
秒杀结束后，按钮按钮变成秒杀已结束。

技术攻关

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

高并发下对服务器数据库造成的极大负载压力。
用户秒杀开始前，通过不断刷新浏览器来保证不会错过秒杀活动。
频繁的访问程序、数据库会对应用服务器和数据库服务器造成负载压力。

网络带宽的问题比超过平时好多倍。
如果秒杀页面的大小为200K，如果最大并发数为10000次，那么需要的网络和服务器带宽是2G（200K×10000）。
这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。

避免直接下单。

秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点之前，只能浏览信息不可下单。
而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。

应对策略

秒杀系统独立部署
为了避免短时间内的大访问量对现有网站业务造成的冲击，可以将秒杀系统独立部署。
如果需要还可以使用独立域名，使其与网站完全隔离。
即使秒杀系统崩溃了，也不会对网站造成影响。

秒杀商品页面静态化

将商品描述、参数、详情，全部写到一个静态页面，不用进行程序的逻辑处理，不需访问数据库。
不用部署动态的服务器和数据库服务器。

租借秒杀活动的网络带宽

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

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

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

架构设计

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

购买按钮只有在秒杀开始的时候才能点亮，在此之前是灰色的，显示活动未开始。
如果页面是动态生成的，每次刷新都要请求服务器，那么势必造成服务端的负载压力。
如果页面是静态页面的话，可以将页面缓存在CDN，反向代理服务器上，甚至用户浏览器上。
但是这样，秒杀开始时，用户刷新页面，根本请求不到应用服务器。

解决方案：

使用JS脚本控制，在页面中引用一个JS文件(文件极小)，但是该文件不要被缓存。
该JS的作用是，包含秒杀开始标志，修改样式，生成下单页面的URL及随机参数。
该JS文件不被缓存的做法：xxx.js?v=随机数。
会有一台服务器进行监控(定时上下架)：
当秒杀活动开始时推送该文件。
当秒杀活动结束时推送文件，标示结束标志，修改样式。
如下图。

如何只允许，第一个提交的单进入订单系统。
由于秒杀到商品的用户只有一个，因此需要在提交订单时，进行下单前置检查。
如果已经有订单提交成功，表示活动结束，进入秒杀结束页面。
事实上，订单数只能有一个，为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口。
只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。
（前置检查逻辑）检查本机已处理的下单请求数目：
如果超过10条，直接返回已结束页面给用户。
如果未超过10条，则用户可进入填写订单及确认页面。
（前置检查逻辑）检查全局已提交订单数目：
已超过秒杀商品总数，返回秒杀结束页面。
未超过秒杀商品总数，提交到子订单系统。

减库存的操作

拍下减库存(用户体验好)

付款减库存

#

另一种思路也值得学习
《秒杀系统架构优化思路》

上周参加Qcon，有个兄弟分享秒杀系统的优化，其观点有些赞同，大部分观点却并不同意，结合自己的经验，谈谈自己的一些看法。

一、为什么难
秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。
例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。
又例如12306抢票，亦与秒杀类似，瞬时流量更甚。

二、常见架构

流量到了亿级别，常见站点架构如上：
1）浏览器端，最上层，会执行到一些JS代码
2）站点层，这一层会访问后端数据，拼html页面返回给浏览器
3）服务层，向上游屏蔽底层数据细节
4）数据层，最终的库存是存在这里的，mysql是一个典型

三、优化方向
1）将请求尽量拦截在系统上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】
2）充分利用缓存：这是一个典型的读多些少的应用场景【一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适合使用缓存

四、优化细节
4.1）浏览器层请求拦截
点击了“查询”按钮之后，系统那个卡呀，进度条涨的慢呀，作为用户，我会不自觉的再去点击“查询”，继续点，继续点，点点点。。。有用么？平白无故的增加了系统负载（一个用户点5次，80%的请求是这么多出来的），怎么整？
a）产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求
b）JS层面，限制用户在x秒之内只能提交一次请求
如此限流，80%流量已拦。

4.2）站点层请求拦截与页面缓存
浏览器层的请求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
a）同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
b）同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面
如此限流，又有99%的流量会被拦截在站点层

4.3）服务层请求拦截与数据缓存
站点层的请求拦截，只能拦住普通程序员，高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎么整？
a）大哥，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”
b）对于读请求，还要我说么？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了

4.4）数据层闲庭信步
到了数据这一层，几乎就没有什么请求了，单机也能扛得住，还是那句话，库存是有限的，小米的产能有限，透这么多请求来数据库没有意义。

五、总结
没什么总结了，上文应该描述的非常清楚了，对于秒杀系统，再次重复下笔者的两个架构优化思路：
1）尽量将请求拦截在系统上游
2）读多写少的常用多使用缓存