秒杀seckill
- 隔离
- 限流
- 削峰
- 异步
- 缓存
从架构、产品、前端、后端四个层面针对秒杀场景（可以扩展到所有高并发场景）分别总结了一些解决方案。
秒杀架构设计原则：
将请求拦截在系统上游
使用缓存
水平扩展
内部系统相互隔离
要点总结：
1.架构： 隔离（业务隔离），分布式（多台机器）
2.产品： 下单按钮控制（断流），答题验证（削峰），精简页面（降流）,抢领分离（异步）
3.业务： 分批发布,只允许认证用户抢，抢购和领取分开，过期回抢。
4.前端： 静态化，限流，风控（反作弊），动态获取抢购地址。
5.后端： 限流，风控（反作弊 IP，UID）；队列（异步） 缓存 程序计数器（数量总和） 分布式锁
一、秒杀一般会带来2个问题：
1、高并发
比较火热的秒杀在线人数都是10w起的，如此之高的在线人数对于网站架构从前到后都是一种考验。
2、超卖
任何商品都会有数量上限，如何避免成功下订单买到商品的人数不超过商品数量的上限，这是每个抢购活动都要面临的难题。
实际上超卖问题是高并发带来的一个子问题，但是因为这个问题太过致命，所以我们把他的解决方案单独拿出来说。
二、如何解决？
1.架构层面：
秒杀架构设计原则：
尽量将请求拦截在系统上游
读多写少的常用多使用缓存
扩容
说白了加机器
系统隔离
为了避免短时间内的大访问量对现有网站业务造成的冲击，可以将秒杀系统独立部署。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。即使秒杀系统崩溃了，也不会对网站造成影响。
数据隔离
将即将被秒杀的热数据维护到redis。秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。
减库存操作
一种是拍下减库存 另外一种是付款减库存；目前采用的“拍下减库存”的方式，拍下就是一瞬间的事，对用户体验会好些。
2.产品层面：
1.控制秒杀商品页面抢购按钮的可用/禁用。
购买按钮只有在秒杀开始的时候才能点亮，在此之前是灰色的，显示活动未开始。
2.增加了秒杀答题，基于时间分片削峰
秒杀答题一个很重要的目的是为了防止秒杀器。还有一个重要的功能，就是把峰值的下单请求给拉长了，从以前的1s之内延长到2~10s左右，请求峰值基于时间分片了，这个时间的分片对服务端处理并发非常重要，会减轻很大压力，另外由于请求的先后，靠后的请求自然也没有库存了，也根本到不了最后的下单步骤，所以真正的并发写就非常有限了。其实这种设计思路目前也非常普遍，如支付宝的“咻一咻”已及微信的摇一摇。
3.秒杀页面设计简化：
秒杀场景业务需求与一般购物不同，用户更在意的是能够抢到商品而不是用户体验。所以秒杀商品页面应尽可能简单并且拍下后地址等个人信息应该使用默认信息，减轻秒杀进行时系统负载，若有更改可以在秒杀结束后进行更改。
3.前端层面
静态化以及页面缓存
将页面能够静态的部分都静态化，并将静态页面缓存于CDN，以及反向代理服务器，可能还要临时租借服务器。
利用 页面静态化、数据静态化，反向代理 等方法可以避免 带宽和sql压力 ，但是随之而来一个问题，页面抢单按钮也不会刷新了，可以把 js 文件单独放在js服务器上，由另外一台服务器写 定时任务 来控制js 推送。 另外还有一个问题，js文件会被大部分浏览器缓存，我们可以使用xxx.js?v=随机数 的方式来避免js被缓存。
限流（反作弊）
1.针对同一个用户id来实现，前端js控制一个客户端几秒之内只能发送同一个请求，后端校验同一个uid在几秒之内返回同一个页面
2.针对同一个ip来实现，进行ip检测，同一个ip几秒之内不发送请求或者只返回同一个页面
3.针对多用户多ip来实现，依靠数据分析
4.为了避免用户直接访问下单页面URL，需要将改URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。
4.后端层面：
1.加入缓存redis：
因为秒杀是典型的读多写少的场景，适合操作内存而非操作硬盘；缓存工具redis本身的操作是保证原子性的，所以可以保证请求了redis的写的操作的线程安全性。
2.加入消息队列，利用队列进行削峰：
将用户请求放置于一个或多个队列中，队列中元素总和等于该商品库存总和，未进入队列的请求均失败。利用多线程轮询分别从一个或多个队列中取出用户请求。操作redis进行减库存操作，成功减库存之后返回成功，并将用户信息与商品信息存入另一个队列当中，进行生成订单的操作。利用两个队列异步处理业务减轻秒杀高峰时期服务器负载。
3.程序计数器：
队列与缓存为了保证请求redis的次数不超过总的库存量，利用一个程序计数器来这一点。程序计数器用JUC包下原子类可以实现。
4.分布式锁
分布式情况下可以利用分布式锁来解决任务每次只能由一次服务来执行且不能重复执行。
分布式锁的实现：zk、redis
分布式锁的优化：先考虑是否可以去锁，然后考虑尽可能多用乐观锁，少用悲观锁。这里有一个问题，乐观锁如果每一次都会有并发冲突的话性能反而不如悲观锁，那么难道真的多用乐观锁性能会比悲观锁高吗？选举考虑ha，比如心跳检测。
5.分布式去锁 方案
利用集群并发加入队列，选举队列处理服务单点执行，这样可以保证并发实现和加锁一样的并发量但不会影响性能。
什么是秒杀 秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于网站中一些稀缺或者特价的产品，电商网站一般会在约定的时间对其进行限量销售，因为这些产品的特殊性，会吸引大量用户前来抢购，并且会在约定时间同时在秒杀页面进行抢购。
设计思路 将请求拦截在系统上游，降低下流压力;秒杀系统特点就是并发量极大，但实际秒杀成功的请求数量确很少，所以如果不在前端拦截可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时，甚至导致系统崩溃 充分利用缓存：利用缓存可以极大提高系统读写速度 消息队列：消息队列可以削峰，将拦截大量并发的请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理
前端方案 浏览器端（js）： 页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素，通过CDN来抗峰值 禁止重复提交：用户提交之后按钮置灰，禁止重复提交 用户限流：在某一时间内只允许用户提交一次请求，比如可以采取IP限流
后端方案 服务器控制器层（网关层） 限制UID（userID）访问频率：我们上面拦截了浏览器的访问请求，但准对某些恶意请求和攻击或者其他插件，在服务器控制层要准对同一个uid，限制访问频率
服务层 上面只拦截了一部分请求，当秒杀的用户量非常大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100w用户同时抢购100台手机，服务层并发请求压力至少为100w。 1.采用消息队列缓存请求：既然服务器层知道库存只有100台手机，那完全没有必要把100w个请求都传递到数据库里，那么可以先把这些请求都写到消息队列里面缓存一下，数据库层订阅消息减少库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束 2.利用缓存应对读请求：对类似12306等购票业务，是典型的读多写少业务，大部分请求时查询请求，所以可以利用缓存分担数据库压力 3.利用缓存对写请求：缓存也是可以应对写请求，比如我们可以把数据库中库存数据迁移到Redis缓存中，所有减库存操作都在Redis中进行，然后通过后台进程把Redis中的用户秒杀请求同步到数据库中
数据库层 数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入的队列和缓存，让底层的数据库高枕无忧