设计一个秒杀系统

一、理解秒杀系统

要做一个秒杀系统，首先要理解秒杀系统。秒杀系统主要解决两个问题，一个是并发读，一个是并发写。并发读的核心优化概念是尽量减少用户到服务端来读数据，或者让用户读更少的数据。并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。

二、秒杀系统设计原则

秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。对于秒杀系统，请求数据要尽量少，路径要尽量短，依赖要尽量少，以及不要有单点。

• 数据要尽量少。指用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据（通常就是网页）。不管是请求数据还是返回数据都需要处理器做处理，而服务器在写网络时都需要亚索和字符编码，这些都非常消耗CPU。所以减少传输的数据量可以显著减少CPU的使用。例如：我们可以简化秒杀页面的大小，去掉不必要的页面装修效果。
• 请求数要尽量少。一次可以请求多个文件，减少请求次数。
• 路径要尽量短。所谓路径就是用户发出请求到返回数据这个过程中需求经过的中间节点数。缩短请求路径可以增加可靠性。要缩短访问路径，就是多个相互强依赖的应用合并部署到一起，把远程方法调用变成JVM内部的方法调用。
• 不要有单点。因为单点意味着没有备份，风险不可控。分布式系统最重要的原则就是消除“单点”。

三、如何减少数据量

用户请求的数据可以分为“静态数据”和“动态数据”。主要区别就是看输出的数据是否包含URL、浏览者、时间等私密数据。个性化的私密数据是动态数据，公有的页面是静态数据。

可以把静态数据进行缓存，比如商品图片等。这样请求的数据量就会减少，减少系统压力。在将整个系统做动静分离后，可以将Cache进一步前移到CDN上，因为CDN离用户更近，效果会更好。

四、流量削峰

对于秒杀系统，当秒杀活动开启时，会有巨量的流量瞬间涌进来。服务器的处理能力是恒定的，一下子处理不了这么多请求。为解决此问题，需要流量削峰。

• 排队

要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用转换成异步的间接推送。中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。在这里，消息队列就像水库一样，拦蓄上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。

如果流量洪峰持续一段时间达到消息队列的处理上限，消息队列同样会被压垮。

• 答题

增加答题环节可以延缓请求，起到对流量进行削峰的作用，从而让系统能够更好的支持瞬时的流量高峰。这个功能就是把峰值的下单请求拉长，从以前的1s之内延长到2s-10s。利用延长的时间，可以大大减缓服务器的压力。

• 分层过滤

加入请求分别经过CDN、前台读系统、后台系统和数据库这几层。那么，大部分数据和流量在用户浏览器或者CDN上读取，这一层可以拦截大部分数据的请求。经过前台系统时数据尽量走Cache，过滤一些无效的请求。第三步数据到后台系统，主要做数据的二次校验，这样数据进一步减少。这样就像漏斗一样，尽量把数据量和请求量一层一层地过滤和减少了。

分层过滤的核心思想是，在不同层次尽可能地过滤掉无效请求，让“漏斗”最末端的才是有效请求。

五、减库存

在正常的电商平台中，用户的实际购买过程分为两个步骤：下单和付款。下单之后，只有完成付款才算真正购买。减库存操作一般有如下几种方式：

• 下单减库存。即当买家下单后，在商品的总库存中减去买家购买数量。下单建库存是最简单的减库存方式，也是控制最精确的一种，这样一定不会出现超卖的情况。但是，有些人下单后并不会付款。
• 付款减库存。即买家下单后，并不立即减库存，而是等到用户付款之后才真正减库存，可能会出现超卖问题。因为并发较高，有可能出现买家下单后付不了款的情况，因为商品已经被其他人买走了。
• 预扣库存。买家下单后，库存为其保留一段时间，超过这个时间，库存会自动释放，释放后其他买家就可以继续购买。

由于参加秒杀的商品，一般都是“抢到就是赚到”，所以下单后却不付款的情况比较少，再加上卖家对秒杀商品的库存有严格限制，所以秒杀商品采用“下单建库存”更加合理。