[TOC]

seckill(秒杀系统)

秒杀场景特点

瞬时大并发：一提到秒杀系统给人最深刻的印象是超大的瞬时并发，这时你可以联想到小米手机的抢购场景，在小米手机抢购的场景一般都会有10w＋的用户同时访问一个商品页面去抢购手机，这就是一个典型的瞬时大并发，如果系统没有经过限流或者熔断处理，那么系统瞬间就会崩掉，就好像被DDos攻击一样；
超卖：秒杀除了大并发这样的难点，还有一个所有电商都会遇到的痛，那就是超卖，电商搞大促最怕什么？最怕的就是超卖，产生超卖了以后会影响到用户体验，会导致订单系统、库存系统、供应链等等，产生的问题是一系列的连锁反应，所以电商都不希望超卖发生，但是在大并发的场景最容易发生的就是超卖，不同线程读取到的当前库存数据可能下个毫秒就被其他线程修改了，如果没有一定的锁库存机制那么库存数据必然出错，都不用上万并发，几十并发就可以导致商品超卖；
性能：当遇到大并发和超卖问题后，必然会引出另一个问题，那就是性能问题，如何保证在大并发请求下，系统能够有好的性能，让用户能够有更好的体验，不然每个用户都等几十秒才能知道结果，那体验必然是很糟糕的；

限流：鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端

削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰：利用缓存和消息中间件等技术

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理也是削峰的一种实现方式

内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘I/O，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升

可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰

限制uid（UserID）访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率（比如12306输入验证码就是一种手段）

当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。所以对请求需要进一步缓存处理

采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库，可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力
利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中

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