一、秒杀系统【并发读、并发写】
1.秒杀时大量用户会在高并发同一时间同时进行抢购，网站瞬时访问流量激增。
2.秒杀一般是访问请求数量远远大于库存数量，只有少部分用户能够秒杀成功。
3.秒杀业务流程比较简单，一般就是下订单减库存。
1.1 设计思路
1.BlockingQueue阻塞队列限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。
2.redis,MQ削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用redis缓存和RocketMQ消息中间件等技术。
3.异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。
4.Redis内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。
5.分布式：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。，分布式带来了一些问题，如分布式事务，分布式锁。
二、前端方案
将请求拦截在系统上游，降低下游压力：秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。 如【河北考试教育院，报名46级，网页进不去是一种解决方案】
页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。
禁止重复提交：用户提交之后按钮置灰，禁止重复提交
用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流
三、服务端方案
1.采用MQ消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
2.利用redis缓存预热应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用redis缓存分担数据库压力。
3.利用redis缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。
4.MQ限流降级：限制或者关闭系统的某些非核心功能，从而把有限的资源保留给更核心的业务，当系统容量达到瓶颈时，我们需要通过限制一部分流量来保护系统，客户端限流，好处是可以限制请求的发出，通过减少发出无用请求从而减少对系统的消耗，服务端限流，好处是可以根据服务端的性能设置合理的阈值。