秒杀架构的实现

标签：控制器   停止   ref   时间   导致   ace   中间   span   自己的   

1.设计思路

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

2.前端方案----浏览器端(js)：

页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。 
禁止重复提交：用户提交之后按钮置灰，禁止重复提交 
用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流

3.后端方案

3.1服务端控制器层(网关层)---------限制uid（UserID）访问频率

3.2服务层

• 采用消息队列缓存请求：比如有100W用户同时抢100台手机，完全没有必要把100W个请求都传递到数据库，以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。

• 利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。

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

案例:利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统，支持多种数据结构。

采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。

对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。

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

秒杀架构的实现

标签：控制器   停止   ref   时间   导致   ace   中间   span   自己的   

原文地址：https://www.cnblogs.com/mcahkf/p/9132584.html