【趁热打铁】秒杀活动

秒杀的本质和目标

这里秒杀指的是电商平台中商家的促销活动，在短时间（可能一上架或者一秒钟）内商品就被一抢而空，而秒杀带来的挑战性问题就是如何在大量的并发请求下，保障服务的可用性、数据一致性、快速响应等问题。

注：恶意刷单、恶意攻击等均会对服务器造成影响，防（保护）也是一种提高服务高可用性、快速响应的一种解决方案。

服务请求流程

解决事情的问题要从事情的本质入手，一个用户的操作到服务响应中间经过了如下7个步骤，解决问题方案也是从以下几个步骤开始入手，当然想DNS、IO等节点是我们很难控制的，我们只能做自己力所能及的事情。

1. 浏览器
2. DNS
3. CDN
4. 负载均衡
5. 网关(Gateway)
6. 业务服务
7. IO

浏览器

减少请求数量

资源不合并处理的缺点：

1. 文件和文件之间有插入请求，增加N-1个网络延迟
2. 每个网络请求都会存在丢包的影响，请求多了网络丢包的影响会更大；
3. keep-alive服务器可能会被断开，不能完成整个keep-alive状态的保持

资源合并也是存在缺点的：

1. 文件样式布局主要由js文件决定，合并后js文件内容会变大，导致首屏渲染变慢
2. 修改了一个js文件，导致整个合并的代码重新加载，缓存失效

减少非必要的数据加载

比如查询商品详情页的时候，最初加载只加载商品的banner图以及商品的基本信息，像商品的详细信息、详细参数以及评论等内容可以按需加载，用户滑动到指定区域再进行加载，这样可以达到节约带宽、减少数据库的IO操作以及cpu消耗的目标。

请求路径最短

减少请求经过的节点数，请求在CDN、负载均衡节点能返回数据的操作，就不要让请求再落到业务服务上了，通过的节点越多，整体服务可用性就越低（不存在100%可用）。例如每个节点服务可用性约为99%，当一个请求经过5个节点后，整体服务可用性降低约为95%了。

浏览器缓存

我们打开浏览器，浏览京东或者淘宝，打开进程管理器，可以看到浏览器占用了服务器大量的内存空间，这是因为他们将大量的数据缓存到用户的浏览器中，通过浏览器缓存机制达到快速浏览以及减少对服务器的压力目的。

验证码

该方法是减少并发量的有效手段之一，尽量这样的做法会带来的不太好的用户体验，例如早期的12306

缓存静态资源

静态资源指的是不同的用户在不同的时间不同的地域访问的这个资源返回的信息是一致的，例如秒杀活动中商品的详情页或者秒杀活动列表等，这些页面再短期内（秒杀活动过程中）所有用户浏览的信息是完全一致的，那么我们可以将这些信息（Xml或者JSON格式的数据）缓存到CDN或者Nginx中，用户在访问到CDN或者Nginx就可以直接获取所需信息，大大的减少了服务器压力。

注：CDN访问基于用户最近访问原则，虽然现在的网络能达到光速，这些消耗可以忽略不计，但是当并发请求大到了一定程度，还是存在影响的，所以在允许的条件范围内减少非必要的消耗为标准

限流、削峰、分层过滤

服务器处理资源能力是有限的，当并发请求量超过的我们的服务器所承受的极限的时候，很容易导致服务器宕机，为了避免服务器宕机造成用户无法访问的现象，我们通常通过限流、削峰、分层过滤等处理方式减少并发量。

限流：通过对并发访问/请求进行限速，或者对一个时间窗口内的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理

削峰：延缓用户请求，把用户的请求的丢到消息队列中，等着服务器来处理。以前的淘宝双11都是在11月11号当天进行，现在的双11改变成了1号到11号都是双11活动，针对不同类型的商品进行限时抢购，这样的做法也是削峰。

分层过滤：和限流本质上没什么区别，只是在请求路径经过的节点中，层层过滤。例如该商品秒杀只有20件商品，但是秒杀开始就接收到了2000请求，我们可以在负载均衡节点进行拦截过滤，放行1000个请求到gateway节点，在gateway节点再次进行拦截过滤，实际落到业务服务的请求只有100个，通过层层过滤达到减少业务服务的压力。

业务服务

减少依赖

优先获取并展示优先级高的信息，例如获取秒杀商品信息接口只获取商品（名称、规格、banner图）等基本信息，详情参数、评论信息等可以按需加载，根据用户需要在加载（这些基本信息也属于静态数据，可以放到CDN或者缓存中）

动态扩容

不管业务服务器怎么设计，单台服务器所能承受也请求数量也是有限的，所以当QPS达到阈值的时候，应该对业务服务集群进行横向动态扩容，能快速创建一台无状态的服务实例（例如k8s的replicates）。

缓存

对于数据的查询，在没有使用缓存的解决方案时，我们只能直接查询数据库，当请求量过大时候，会对数据库造成非常大的压力，甚至导致数据库宕机，针对读多写少的请求使用缓存可以有效的减少业务服务器的压力（因为请求查询到缓存有数据直接返回缓存的数据，并不会再查询数据库了）。

局部削峰

业务服务内，局部削峰可以使用Queue、锁、序列化（Serialization）等方式进行削峰

热点数据

所有的商品信息存在数据库中都被称之为数据，而在营销活动中，大量用户关注的商品可以称为热点数据，而热点数据就是我们更应该关注的。例如本来今天对商品A进行限时秒杀活动，我们也针对商品A进行了多种方案的应急处理，这时候突然商品引入了大量的流量，这时候商品B的请求压力就会大的多，如果我们没有一个很好的应急方案，那么服务器就很容易宕机。

数据收集

请求在落到业务服务器之前会通过DNS、负载均衡、gateway等多个节点，我们可以在这些节点对请求的数据进行收集分析。

数据识别

收集的数据可以通过数据分析、BI、预知等方式识别，推断出接下来哪些商品可能会大卖

处理方式

1. 单独处理：将业务服务器进行扩容部署，而扩容的服务器集群单独进行营销活动（例如秒杀功能），请求通过负载均衡、gateway节点时，将秒杀该商品的请求转发到独立部署的业务服务集群
2. 分桶处理：每处理某一种（类）商品的服务器集群只处理指定的一种（类）商品，不能因为该集群服务挂掉而把流量分到其他的服务集群中，这样会很容易导致其他的服务器集群流量激增，从而营销了其他的营销活动（流量激增容易导致服务器宕机）。