高并发大流量秒杀方案思路

概念：什么是秒杀

秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于网站中一些稀缺或者特价的产品，电商网站一般会在约定的时间对其进行限量销售，因为这些产品的特殊性，会吸引大量用户前来抢购，并且会在约定时间同时在秒杀页面进行抢购。

秒杀系统场景的特点

1）秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问量激增。
2）秒杀一般是访问请求数量远远大于库存数量，只有少部分用户能够秒杀成功
3）秒杀业务流程比较简单，一般就是下订单减库存。

秒杀架构设计的理念

限流： 鉴于只有少部分用户能够秒杀成功，所以要限制部分流量，只允许少部分流量进入服务器后端。
消峰： 对应秒杀系统瞬时会有大量用户涌入，所以在抢购一开始就会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原理，所以如何把瞬间的高流量变成一段平稳的流量也是设计秒杀系统很重要的思路，实现消峰的常用方法利用缓存和消息中间件技术
异步处理： 秒杀系统是一个高并发系统，采用异步处理模式可以极大的提高系统并发量，其实异步处理就是消峰的一种实现方式
内存缓存： 秒杀系统最大的瓶颈一般是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大的提升
可扩展性： 当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可扩展的，如果流量来了，扩展机器就好了，像淘宝，京东双十一活动就会增加大量机器应对交易高峰

设计思路

将请求拦截在系统上游，降低下流压力：秒杀系统特点就是并发量极大，但实际秒杀成功的请求数量确很少，所以如果不在前端拦截可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时，甚至导致系统崩溃

充分利用缓存：利用缓存可以极大提高系统读写速速

消息队列：消息队列可以削峰，将拦截大量并发的请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理

前端方案

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

后端方案

服务器控制器层（网关层）
限制UID（userID）访问频率：我们上面拦截了浏览器的访问请求，但准对某些恶意请求和攻击或者其他插件，在服务器控制层要准对同一个uid，限制访问频率

服务层
上面只拦截了一部分请求，当秒杀的用户量非常大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100w用户同时抢购100台手机，服务层并发请求压力至少为100w。
1）采用消息队列缓存请求：既然服务器层知道库存只有100台手机，那完全没有必要把100w个请求都传递到数据库里，那么可以先把这些请求都写到消息队列里面缓存一下，数据库层订阅消息减少库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束
2）利用缓存应对读请求：对类似12306等购票业务，是典型的读多写少业务，大部分请求时查询请求，所以可以利用缓存分担数据库压力
3）利用缓存对写请求：缓存也是可以应对写请求，比如我们可以把数据库中库存数据迁移到Redis缓存中，所有减库存操作都在Redis中进行，然后通过后台进程把Redis中的用户秒杀请求同步到数据库中

数据库层
数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入的队列和缓存，让底层的数据库高枕无忧

案例：利用消息中间件和缓存实现简单的描述系统

Redis 是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。
我们可以采用Redis最简单的key-value数据结构，用一个原子类型的变量值作为key，把用户id作为value，库存数量便是原子变量的最大值，对于每个用户的秒杀，我们使用RPUSH key value 插入秒杀请求，当插入的秒杀请求数量达到上限时，停止所有后续插入。
然后我们可以在后台启动多个工作线程，使用LPOP key 读取秒杀成功者的id，然后在操作数据库做最终的下单减库操作
当然，Redis可以换成 消息中间件 ActiveMQ，RabbitMQ，也可以将缓存和消息中间件组合起来，缓存系统负担接收记录用户请求，消息中间件负责将缓存中的请求同步到数据库

电商网站一般架构

秒杀第一个版本

秒杀系统架构图

秒杀系统需要独立出来

秒杀问题
现有业务冲击（将秒杀服务独立出来）
高流量大并发（redis缓存处理、MQ异步处理订单请求）
网络带宽突增（秒杀活动时增加带宽、CDN+OSS缓存静态文件）
超卖（redis队列缓存商品数量防止并发出现超卖现象）
防止黄牛（IP限制次数）

解决方案
单独部署
限流 熔断
缓存
CDN+OSS
消息队列