文章目录

秒杀的本质和目标
服务请求流程
- 浏览器
- - 减少请求数量
  - 减少非必要的数据加载
  - 请求路径最短
  - 浏览器缓存
  - 验证码
- 缓存静态资源
- 限流、削峰、分层过滤
- 业务服务
- - 减少依赖
  - 动态扩容
  - 缓存
  - 局部削峰
- 热点数据
- - 数据收集
  - 数据识别
  - 处理方式

秒杀的本质和目标

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

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

服务请求流程

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

浏览器
DNS
CDN
负载均衡
网关(Gateway)
业务服务
IO

浏览器

减少请求数量

资源不合并处理的缺点：

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

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

文件样式布局主要由js文件决定，合并后js文件内容会变大，导致首屏渲染变慢
修改了一个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、预知等方式识别，推断出接下来哪些商品可能会大卖

处理方式

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

【趁热打铁】秒杀活动相关推荐

【硬核】秒杀活动技术方案，Redis申请32个G，被技术总监挑战了...
作为一名技术从业人员,性能优化是每个人的必修课就像大学时期给漂亮妹子修电脑的绝招就是"重启电脑一样",性能优化也有自己的必杀技你一定听过一句话:性能不够,缓存来凑!对,你没听错 ...
业务总结002:秒杀活动架构设计
一.秒杀商品模型二.架构设计 2.1 Redis + MQ 缓存预热:秒杀商品一般时效性比较强,一场秒杀活动持续的时间不会很长,当在后台设置秒杀活动添加秒杀商品时,把商品对应的库存直接存到 Redi ...
阿里双11大促秒杀活动下的缓存技术与高水位限流实现
秒杀最早来自天猫双11各种商品的促销活动中,现在已经有很多业务场景在使用,比如抢红包,抢票等.其特点有三高:瞬时并发高,数据一致性高,热点更新频度高.这样三高的场景下往往给数据库造成极大的压力,大量更 ...
小程序秒杀活动服务器,一套实用的小程序秒杀活动方案，亲这边建议你收藏哦...
小伙伴们好~今天,上线君为大家给总结的是小程序秒杀活动的使用方案,大部分行业都能够参考使用,大家可以收藏学习. 图片来源:pexels ▼活动前期:确定目标与流程与团购活动不一样,对秒杀活动来说,时 ...
华为官方翻新产品秒杀活动来袭，官方正品，7折优惠，真香！
4月24日,@华为商城微博官宣,4月26日12:00和20:00在华为商城APP内将举办两场超级秒杀节活动,其中包括7折优惠的2款华为官方翻新手机,分别是nova 9和nova 9 Pro.华为官方 ...
阿里、百度、美团都在用的‘’高并发秒杀系统‘’；抢红包、秒杀活动、微博热搜、12306抢票等高并发场景
"秒杀活动"."抢红包"."微博热搜"."12306抢票"."共享单车拉新"等都是高并发的典型业务场 ...
一度智信：拼多多商家参与秒杀活动好处
今天小编就给大家分享关于拼多多商家秒杀活动的一些相关内容,操作好了对店铺来说也是大大有益的. 一.什么是秒杀活动拼多多的活动如果要划分等级的话,秒杀活动算是高级活动,流量短期内会有很大的导入,同样的 ...
秒杀活动，提高性能，防止超卖，订单超时
目录初步思考秒杀活动订单防止超卖订单超时如何处理初步思考原文地址前端:页面尽可能静态化,css/js合并,减少请求数扩容:增加机器,提高处理请求能力限流:应用限流(nginx,tom ...
高并发下商城秒杀活动的处理
秒杀抢购活动是现在很多商城常见的营销手段,小米抢购.淘宝的整点免单.聚划算等都是成功的例子. 从简单处着手,秒杀是很好理解的:设置要秒杀的商品的数量,抢完为止.但是,实际应用中一瞬间的高并发压力.以及 ...

【趁热打铁】秒杀活动