秒杀系统设计

系统的特点

• 高性能：秒杀涉及大量的并发读和并发写


• 一致性：主要是商品超卖问题


• 高可用：秒杀时会在一瞬间涌入大量的流量，为了避免系统宕机，保证高可用，需要做好流量限制

优化思路

将请求尽量拦截在系统上游

后端优化

• 限流：屏蔽掉无用的流量，允许少部分流量走后端。


• 削峰：秒杀请求在时间上高度集中于某一个时间点，瞬时流量容易压垮系统，因此需要对流量进行削峰处理，缓冲瞬时流量，尽量让服务器对资源进行平缓处理


• 异步：将同步请求转换为异步请求，来提高并发量，本质也是削峰处理


• 利用缓存：将商品信息放在缓存中，减少数据库查询


• 负载均衡：利用Nginx等使用多个服务器并发处理请求，减少单个服务器压力

前端优化

• 限流：前端答题或验证码，来分散用户的请求


• 禁止重复提交：限定每个用户发起一次秒杀后，需等待才可以发起另一次请求，从而减少用户的重复请求


• 本地标记：用户成功秒杀到商品后，将提交按钮置灰，禁止用户再次提交请求


• 动静分离：将前端静态数据直接缓存到离用户最近的地方，比如用户浏览器、CDN 或者服务端的缓存中

防作弊优化

• 隐藏秒杀接口


• 验证码


• 同一ip多次请求


• 多个账号不同IP发起不同请求：检测账号的活跃度或者等级等信息，来进行限制

系统隔离

业务隔离

当成一个单独的业务来处理。在活动开始之前，最好设计一个“热场”。“热场”的形式多种多样，例如：分享活动领优惠券，领秒杀名额等等。“热场”的形式不重要，重要的是通过它获取一些准备信息。

例如：有可能参与的用户数，他们的地域分布，他们感兴趣的商品。为后面的技术架构提供数据支持。

技术隔离

• 客户端：前端秒杀页面使用专门的页面，这些页面包括静态的HTML和动态的JS，他们都需要在CDN上缓存。


• 接入层：加入过滤器专门处理秒杀请求，即使我们扩展再多的应用，使用再多的应用服务器，部署再多的负载均衡器，都会遇到支撑不住海量请求的时候。
  
  所以，在这一层我们要考虑的是如何做好限流，当超过系统承受范围的时候，需要果断阻止请求的涌入。


• 应用层，瞬时的海量请求好比请求的“高峰”，我们架构系统的目的就是“削峰”。
  
  需要使用服务集群和水平扩展，让“高峰”请求分流到不同的服务器进行处理。同时，还会利用缓存和队列技术减轻应用处理的压力，通过异步请求的方式做到最终一致性。
  
  由于是多线程操作，而且商品的额度有限，为了解决超卖的问题，需要考虑进程锁的问题。

数据库隔离

秒杀活动持续时间短，瞬时数据量大。为了不影响现有数据库的正常业务，可以建立新的库或者表来处理。

在秒杀结束以后，需要把这部分数据同步到主业务系统中，或者查询表中。如果数据量特别巨大，到千万级别甚至上亿，建议使用分表或者分库。