秒杀系统设计

http://blog.51cto.com/13527416/2085258

限流

由于活动库存量一般都是很少，对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器

削峰

秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷，一般的采用缓存和 MQ 中间件来解决

异步

秒杀其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性

缓存

秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提高并发效率

• 尽量将请求拦截在上游，降低下游的压力
• 充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用

秒杀系统核心在于层层过滤，逐渐递减瞬时访问压力，减少最终对数据库的冲击。通过上面流程图就会发现压力最大的地方在哪里？

MQ 排队服务，只要 MQ 排队服务顶住，后面下订单与扣减库存的压力都是自己能控制的，根据数据库的压力，可以定制化创建订单消费者的数量，避免出现消费者数据量过多，导致数据库压力过大或者直接宕机。

库存服务专门为秒杀的商品提供库存管理，实现提前锁定库存，避免超卖的现象。同时，通过超时处理任务发现已抢到商品，但未付款的订单，并在规定付款时间后，处理这些订单，将恢复订单商品对应的库存量

https://segmentfault.com/q/1010000000199149
有一个秒杀商品，只有10件，10万人来秒 怎么弄

我觉得这里有三个问题，1.公平，2.商品卖光，3.缓解系统压力。
公平如何保证：

• 先到先得：先来的自然要让他们进来（秒杀开始前的一律挡掉），10个商品的秒杀，秒杀开始后先来的100（经验值）个挨个进入mq，之后的挡住。然后对100挨个返回交易界面，填写信息确认。
• 防止机器人：返回的交易界面，自然要填写验证码。

商品卖光：

• 刚才说的100个，是10个商品的10倍，保证这些用户能够消费这10个商品。（当然可以利用历史数据做优化）

缓解系统压力：

• 保证前两个的前提下。当然你可以直接放1w个用户进来，但没必要。
• 只有100个用户了，对数据库的压力也就小了。用户收到交易页面后，手快的，先得。在处理他们交易的时候当然是要加锁的。 我觉得加锁有两个方法，一个是对总量n加锁,交易的时候其他用户不能改，交易完减1，另一个是对于10个变量分别加锁，这样会快一点。

先考虑各种方法降低你的数据库负载。

然后再考虑秒杀的公平性。

所以嘛，比如，你可以根据请求的时间戳做个规则，把 99% 甚至更多的请求直接扼杀在摇篮之中。

剩下的 1% 或者更少的请求再考虑按照公平的方法去竞争那为数不多的名额。

redis 啊，mq 啊，MySQL 事务啊，反正流量下来的，用啥都行。