设计一个秒杀系统（模块）

场景特点：

1，多用户同时访问，瞬间访问流量激增；
2，访问请求大于库存，较少能得到商品；
3，下订单减库；

架构设计

1，限流：少部分客户能得到商品，则限制大部分流量，允许少部分流量进入服务后端；
2，削峰：用缓存和消息中间件等把瞬间高流量变为平稳的流量；
3，异步：异步处理模式可以极大地提高系统并发量；
4，内存缓存：部分数据或业务逻辑从常规的磁盘 I/O 转到内存，提高效率；
5，可拓展：实现系统弹性可拓展解决更大的流量：当流量到时，拓展机器就准备完成；

架构方案

页面->服务端控制器（网关）->服务层->数据库层；

设计思路

1，将请求拦截在系统上游，降低下游压力：秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很 少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
2，充分利用缓存：利用缓存可极大提高系统读写速度。
3，消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。

前端设计

JS：禁止重复提交
用户限流：一段时间内，只允许提交一次，可用IP限流等；
前端静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。

后端设计

1，限制UID访问频率：服务端控制层对同一个UID限制频率，防止“黑恶势力”；

2，采用消息队列缓存请求：既然服务层知道库存只有100台手机，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。

3，大部分请求是查询请求，所以可以利用缓存分担数据库压力。

4，利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

数据库

数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。确实需要承担较大压力的时候：设计数据库主从模式，主写从读。

案例：利用消息中间件和缓存实现简单的秒杀系统
Redis是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。

当然，上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等，也可以将缓存和消息中间件 组合起来，缓存系统负责接收记录用户请求，消息中间件负责将缓存中的请求同步到数据库。