业务特点
1、瞬时并发量大，秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增几倍、甚至几十倍以上
2、库存量少，一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。
3、业务和流程较为常见，一般都是下订单、扣库存、支付订单。
技术难点
1、若秒杀活动若与其他营销活动同时进行，可能会对其他活动造成冲击，极端情况下可能导致整个服务宕机。
2、页面流量突增，秒杀活动用户访问量会突增。需确保访问量的突增不会对服务器、数据库、Redis 等造成过大的压力。
3、秒杀活动库存量小，瞬时下单量大，易造成超卖现象
架构设计思想
1、限流：由于库存量很少，对应的只有少部分用户才能秒杀成功。所以要限制大部分用户流量，只准少量用户流量进入后端服务器。
2、削峰：秒杀开始瞬间，大量用户进来会有一个瞬间流量峰值。把瞬间峰值变得更平缓是设计好秒杀系统关键因素。一般的采用缓存和 MQ 实现流量的削峰填谷。
3、异步：秒杀可以当做高并发系统处理。即可以从业务上考虑，将同步的业务，设计成异步处理的任务。
4、缓存：秒杀瓶颈主要体现在下单、扣库存的数据操作中。关系型数据库写入和读取效率较低。若将部分操作放到缓存中能极大提高并发效率 (如使用 Redis 操作库存)。
5、扩容：增加服务器数量和数据库、缓存等服务端的数量，物理层面增大处理并发请求的能力。
客户端优化
1、秒杀页面：
如果秒杀页面的资源，如：CSS、JS、图片、商品详情等都经后端，服务肯定承受不住。如果将这个页面进行静态化，秒杀时肯定能起到压力分散的作用。
2、防止提前下单：使用 JS 控制提交订单按钮，如果非秒杀时间或者已秒杀完成，就不能点击该按钮。
服务端优化
1、对查询秒杀商品进行优化
将首次查询到的商品信息进行数据放入缓存，后面再访问时直接返回缓存的信息。
2、对库存的优化
在设置秒杀活动时就将商品库存放于 Redis 中，在下单扣库存时，直接对 Redis 进行操作。
3、后端流量控制优化（参加用户量过大时）
使用消息队列、异步处理等方式解决。即超过系统水位线的请求直接拒绝掉。
4、部署多台服务器，配置负载均衡。
5、部署多台数据库，代码层面开启数据库的读写分离、提高数据库的可用性。
6、优化数据库查询语句，避免技术原因过多占用数据库资源。
核心思想
1、层层过滤，逐渐递减瞬时访问，降低下游的压力，减少最终对数据库的冲击
2、充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用
3、增强服务器抗并发能力