一、为什么难

秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。

例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。

防止卖超。

二、常见架构

流量到了亿级别，常见站点架构如下：

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）读多写少的常用多使用缓存

下面来一个例子：

之前在一个微信公众号上做了一个抢京东券的功能， 50 张京东券，面额 50 、 100 不等，存在一张 card 表中，四个字段， id ， number ， money ， is_taken 。

因为之前没有这种高并发处理的经验，所以使用了一种最传统的方式来实现：

方案一:来一个人我就从数据库中取一张京东券出来给他，并将该京东券标记为已使用（即更新 is_taken 字段），并将该用户插入到 winner 表中

这个方案最终导致的悲剧是，有一张京东券被两个人领取到了。

我所理解会出现这个问题的原因是获取未被占用的京东券数据（ select ）和更新该条京东券数据（ update ）是两个独立的操作，在这两个操作之间存在时间间隔，例如 A 用户刚得到了一张 100 元的京东券，还未来得及更新， B 用户涌入查询到这张京东券未被使用，所以 B 用户也获得了这张京东券。

问题一：我这个理解是正确的吗？还是有更深入的原因？

出了这个问题后，我在网上查找关于高并发相关的资料，

几乎都提到了队列和锁。就我个人了解队列可以使用 redis 或者 memcacheq(这个没用过，不熟悉)，

所以自己想了第二种方案。

方案二：事先将京东券 id 数据压入到 redis 的 list 中，每过来一个有效的用户，就 pop 一个 id 给他（当 pop 出来的数据为空时说明京东券已经被抢光），并将用户 id 与京东券 id 的对应关系存储到 redis 的 set 当中去，然后根据这个 id 来查找京东券数据，显示给用户京东券的面额，并将 set 中的数据存储到数据库当中去。

方案二

可行。

因为你的业务逻辑比较简单，也可以使用redis的计数器

即当计数器 <=50 时按顺序一人领一张，通过计数器来过滤

问题三 锁

悲观锁(Pessimistic Lock)

顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

begin;

select * from card where is_token=0 limit 1 for update;

乐观锁

顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。参考改进后的方案一。

此文章来源于网络