业务特点：
1、瞬时并发量大，秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增几倍、甚至几十倍以上
2、库存量少，一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。
3、业务和流程较为简单，一般都是下订单、扣库存、支付订单。

技术难点：
1、若秒杀活动若与其他营销活动同时进行，可能会对其他活动造成冲击，极端情况下可能导致整个服务宕机。
2、页面流量突增，秒杀活动用户访问量会突增。需确保访问量的突增不会对服务器、数据库、Redis等造成过大的压力。
3、秒杀活动库存量小，瞬时下单量大，易造成超卖现象

架构设计思想
1、限流：由于库存量很少，对应的只有少部分用户才能秒杀成功。所以要限制大部分用户流量，只准少量用户流量进入后端服务器。
2、削峰：秒杀开始瞬间，大量用户进来会有一个瞬间流量峰值。把瞬间峰值变得更平缓是设计好秒杀系统关键因素。一般的采用缓存和MQ实现流量的削峰填谷。
3、异步：秒杀可以当做高并发系统处理。即可以从业务上考虑，将同步的业务，设计成异步处理的任务。
4、缓存：秒杀瓶颈主要体现在下单、扣库存的数据操作中。关系型数据库写入和读取效率较低。若将部分操作放到缓存中能极大提高并发效率(如使用Redis操作库存)

整体架构

一、客户端优化
1、秒杀页面：
如果秒杀页面的资源，如：CSS、JS、图片、商品详情等都经后端，服务肯定承受不住。如果将这个页面进行静态化，秒杀时肯定能起到压力分散的作用。
2、防止提前下单：
使用JS控制提交订单按钮，如果秒杀时间，就不能点击该按钮。

二、服务端优化
1、对查询秒杀商品进行优化
将首次查询到的商品信息进行数据放入缓存，后面再访问时直接返回缓存的信息。
2、对库存的优化
在设置秒杀活动时就将商品库存放于Redis中，在下单扣库存时，直接对Redis进行操作。
3、后端流量控制优化（参加用户量过大时）
使用消息队列、异步处理等方式解决。即超过系统水位线的请求直接拒绝掉。

核心思想：
1、层层过滤，逐渐递减瞬时访问，降低下游的压力，减少最终对数据库的冲击
2、充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用