秒杀场景 高并发

一、秒杀业务理解

---

1、im系统，每个人都读自己的数据，例如微信；
2、微博系统，每个人读你关注的人的数据，一个人读多个人的数据；
3、秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据。
例如：双11，小米抢购

最常吐槽的，12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这个高并发或者秒杀最难的地方。

二、常用解决办法

---

常用解决方法

（1）将请求尽量拦截在web端（不要让锁冲突落到数据库或者有限的资源上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，最后大部分请求都超时，流量虽大，成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。

（2）充分利用缓存，秒杀买票，这是一个典型的读多写少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。

三、先说说常见的请求结构

---

常见的站点架构基本是这样的，抽象的图，看不懂可以补充学习一下

（1）浏览器端，最上层，会执行到一些JS代码，这一部分也可能是app,或者其他客户端
（2）站点层，这一层会访问后端数据，常见的nginx等等，拼html页面返回给浏览器
（3）服务层，向上游屏蔽底层数据细节，提供数据访问，这个基本都是业务服务器
（4）数据层，最终的库存是存在这里的，DB,包括缓存，对数据直接处理

四、各层次优化细节

---

第一层，客户端处理高并发（浏览器层，APP层）

最常见的一个场景就是用户多次点击，比如用户查询，

（a）产品层面，用户点击“查询”，或者其他读取操作后，按钮置灰，禁止用户重复提交请求；

（b）JS层面，限制用户在x秒之内只能提交一次请求；

APP层面，可以做类似的事情，虽然你疯狂的在摇微信，其实x秒才向后端发起一次请求。这就是所谓的“将请求尽量拦截在系统上游”，越上游越好，浏览器层，APP层就给拦住，这样就能挡住80%+的请求，这种办法只能拦住普通用户（但99%的用户是普通用户）对于群内的高端程序员是拦不住的。firebug一抓包，http长啥样都知道，js是万万拦不住程序员写for循环，调用http接口的，所以阿狸的月饼事件就是这么爆发的。

第二层，站点层面的请求拦截

其实大多数人想到的是对ip，cookie_id,能想到这些说明你是一个合格程序猿，不过有一种场景那就是通常一个ip会有多人个人使用，比如现在网络运营商，现在网费很便宜，其实对于他来说，就是多个人使用一个ip对外链接，只不过自己又做了一层路由，使用ip拦截，这样就把你的大多数客户拦截在外，是不是很郁闷。

解决这种场景的最简单的方式就是注册，没想到吧，有人说我不想注册，那还有一个简单办法是用户自己的唯一编码，类似uuID这种，进行限制，完美解决。具体实施

缓存，页面缓存，同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面。同一个item的查询，例如车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面。如此限流，既能保证用户有良好的用户体验（没有返回404）又能保证系统的健壮性（利用页面缓存，把请求拦截在站点层了）。

页面缓存不一定要保证所有站点返回一致的页面，直接放在每个站点的内存也是可以的。优点是简单，坏处是http请求落到不同的站点，返回的车票数据可能不一样，这是站点层的请求拦截与缓存优化。

好，这个方式拦住了写for循环发http请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。

第三层 服务层来拦截（反正就是不要让请求落到数据库上去）

服务层怎么拦截？别忘了，咱们是程序猿，admin用户就是咱，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？没错，请求队列！

对于写请求，做请求队列，每次只透有限的写请求去数据层（下订单，支付这样的写业务）

1w部手机，只透1w个下单请求去db

3k张火车票，只透3k个下单请求去db

如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”。

对于读请求，怎么优化？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的。如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。
 

当然，还有业务规则上的一些优化。回想12306所做的，分时分段售票，原来统一10点卖票，现在8点，8点半，9点，...每隔半个小时放出一批：将流量摊匀。

其次，数据粒度的优化：你去购票，对于余票查询这个业务，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票？流量大的时候，做一个粗粒度的“有票”“无票”缓存即可。

最后，一些业务逻辑的异步：例如下单业务与 支付业务的分离。这些优化都是结合 业务 来的，我之前分享过一个观点“一切脱离业务的架构设计都是耍流氓”架构的优化也要针对业务。

 

第四层 最后是数据库层

浏览器拦截了80%，站点层拦截了99.9%并做了页面缓存，服务层又做了写请求队列与数据缓存，每次透到数据库层的请求都是可控的。db基本就没什么压力了，闲庭信步，单机也能扛得住，还是那句话，库存是有限的，小米的产能有限，透这么多请求来数据库没有意义。

全部透到数据库，100w个下单，0个成功，请求有效率0%。透3k个到数据，全部成功，请求有效率100%。

五、最后的语言，不是最后的结局

---

上文应该描述的非常清楚了，没什么总结了，对于秒杀系统，再次重复下我个人经验的两个架构优化思路：
（1）尽量将请求拦截在系统上游（越上游越好）；

（2）读多写少的常用多使用缓存（缓存抗读压力）；

web和APP：做限速,（当然产品要做好，不然锅你背）

站点层：按照uid做限速，做页面缓存（给前端开发来点水果，哈哈）

服务层：按照业务做写请求队列控制流量，做数据缓存（背锅侠的位置，写不好祭天）

数据层：闲庭信步（一般DBA,没啥事，脾气大，不要惹他们）

其他的需要你的头脑风暴，欢迎留言