关于高并发:图解-聊聊秒杀

1. 需要剖析

“秒杀”这个词在电商行业中呈现的频率较高，如京东或者淘宝平台的各种“秒杀”流动，最典型的就是“双 11 抢购”。

“秒杀”是指在无限的工夫内对无限的商品数量进行抢购的一种行为，这是商家以“高价量少”的商品来获取用户的一种营销伎俩。

01. 功能性需要

其实，整个秒杀的业务场景并不简单，可即查看参加秒杀的商品信息，加上购买和领取的动作，如下图所示。

秒杀业务最大的挑战在于 3 点：

• 刹时： 持续时间极短，对于热门且具备极强竞争力的商品通常只有一秒。
• 流量微小： 因为价格低廉，商品性价比高，而且失常买是须要很高的价格，所以才会吸引大量的用户来争抢。
• 数量无限： 因为商品的高价且性价比高，所以只有很无限的商品数量参加秒杀。

同时，在保障高并发流量承接的前提下，为了加强用户的体验和流动规定的公平性，以及避免受到歹意毁坏等，特此减少如下需要：

（1）用户在秒杀页面无需始终刷新“抢购”按钮，待秒杀流动开始时，按钮主动点亮。

（2）在偏心以及避免歹意毁坏的准则下，在下单之前减少验证码的录入，或者答题的相干环节。

（3）库存不能呈现问题，即不多扣也不少扣。

（4）整个秒杀流动过程继续 10 分钟。

02. 性能指标预估

通过秒杀的需要形容可得出，以后秒杀流动次要须要预估三块的性能指标：存储容量、并发量、网络带宽。

1）存储容量

因为是秒杀流动，且参加的商品根本都是高价高性价比的，数量是十分无限的。所以，在订单存储上根本不必去过多思考。

2）并发量

针对 5000 万用户均匀每人拜访 2 次，则并发量为每秒 16.7 万左右（5000w2/1060）, 在预留一部分，能够预估到每秒 25 万左右（也能够进行 double 下）。

3）网络带宽

在带宽方面，须要进行相干优化，采取数据传输越少越好，假如单条传输在 0.5KB，则依据并发量预估网络带宽为：977Mb 左右（25w0.5KB=122MB8bit=977Mb）。

03. 非功能性需要

做任何零碎都要思考非功能性需要，特地是公司的外围零碎， 以后秒杀业务零碎非功能性需要次要体现在如下几点：

• 高可用 ，在秒杀流动的整个继续期间内，都能对用户提供服务。
• 高性能 ，让每个用户都能感触到极快的秒杀响应，不能呈现大批量用户提早较高的景象。
• 可扩大 ，当流量比预期更高时，有平滑扩大的策略（也有局部产品设计成敌对的回绝策略）。

2. 概要设计

通过对秒杀业务的自身认知以及下面提到的秒杀业务需要，本次秒杀零碎须要着重设计如下几点：

（1）动静拆散：如何保障用户在不刷新页面的状况下，仍然能进行秒杀相干数据的获取且不会耽搁秒杀流动的开始。

（2）流量分层，针对微小流量，如何进行无效的防控，免得造成后盾服务的不堪重负，以及如何防止前端页面的卡死。

（3）高可用：如何确保后盾继续提供服务。

（4）扣减库存：如何无效扣减库存。

01. 动静拆散

动静拆散是指，将动态页面与动静页面（或者静态数据与动态数据）解耦拆散，用不同零碎承载对应流量。这样能够晋升整个服务拜访性能和可维护性。

商品秒杀页面的静态数据以及动态数据，均是不同的中央提供，如下图所示。

静态数据是指，页面中简直不怎么变动的数据（即不根据用户的 Cookie、根本信息、地区，及工夫等各种属性来生成的数据），例如：

• CSS 和 JavaScript 中的动态文件。
• 流动页中的 HTML 动态文件。
• 图片等相干资源文件。
• 其余与用户信息无关的静态数据。

对于这种分离出来的静态数据能够进行缓存。在缓存之后，这些静态数据的拜访效率就进步了，零碎也更快了。能够应用代理服务器进行静态数据的缓存。

动态数据是指，根据以后用户属性动静生成的数据，在浏览淘宝首页时，每个用户所看到的商品都是不一样的，这就是淘宝的“千人千面”——针对不同用户做不同的举荐；在百度搜寻中是根据不同用户的输出条件，以及用户的习惯给出不同的后果页。这其中的数据就是动态数据。

02. 流量分层

在“秒杀”业务中，商品价格具备弱小的吸引力，所以会受到很多用户的关注，然而商品数量是无限的。所以，在千万的用户中可能只有 100 人能失去商品，对于零碎来说，有 90% 以上的流量属于有效流量。

“秒杀”业务心愿有大量的用户来关注“秒杀”流动，然而在用户真正下单时又不能将这些流量全副放过，所以，须要设计一套高效的流量管控计划，来无效地管制申请流量，过滤掉没必要的流量。

对于刹时流量洪峰能够采纳倒三角的分层级逐层管制形式，共分为 CDN、反向代理（Nginx）、后端服务及 DB 这四个层级。接下来，就来看看每一层级是怎么管制流量的，如下图所示。

03. 高可用

要想在整个“秒杀”流动继续期间内，仍然能对用户提供良好的体验，则秒杀零碎架构在设计时不能设计成单节点的架构。

单节点是所有零碎设计中的大忌，因为单节点零碎意味着零碎的不稳定性较高，可能会呈现不可用的状况，会给企业带来间接的损失。在零碎设计（特地是“秒杀”这类对高并发要求极高的零碎）时，必须保证系统的高可用，如下图所示。

04. 扣减库存

对于“秒杀”流动，通常，公司是不容许商品超卖（即下单胜利的数量不能大于商品存存数量）的。一旦超卖，则会给公司造成损失。如果被歹意流量利用，则损失是微小的。

库存对于电商平台来说是一个重要的业务指标，所以在技术上须要正当设计扣减库存，不能呈现“超卖”景象。通常，扣减库存常有以下 3 种形式：

• 下单扣库存：在用户下单后就扣减库存。
• 领取扣库存：用户付完款后再扣减库存。
• 预扣库存：在用户下完订单后，零碎会为其锁定库存一段时间，在超过锁定工夫后会主动开释锁定的库存。

05. 零碎架构设计

依据下面探讨，针对以后秒杀架构如下图所示。

如上架构比拟简洁，次要分为以下 5 层。

• 用户层：用户端的展示局部，次要波及商品的相干信息及以后“秒杀”流动的信息。
• CDN 层：缓存“秒杀”流动的动态资源文件。
• 负载平衡层：拦挡申请及散发路由等。
• 服务层：“秒杀”流动的具体交易的相干逻辑解决。
• 基础设施层：数据存储、大数据计算及音讯推送相干操作。

其部署架构图如下：

3. 具体设计

01. 动静拆散设计

施行动静拆散架构能够采纳“分而治之”的方法，行将动态数据和静态数据解耦，别离应用各自的架构零碎来承载对应的流量：

• 对于静态数据，举荐缩短用户申请门路，因为门路越短，访问速度也就越快。另外，即尽可能将静态数据缓存起来。
• 对于动态数据，个别用户端须要和服务端进行交互能力获取，所以，申请门路较长，访问速度会慢一点。下图展现了动静拆散计划。

静态数据访问速度很快，而动态数据访问速度较慢。那么试想下，能够将须要动静获取的数据给提前生成好，而后应用动态页面减速技术来拜访吗？如果这样能够，那动态数据拜访的速度就变快了。

这样是能够的，须要用到比拟风行的“页面动态化”技术。页面动态化技术是指，间接缓存 HTTP 连贯，而不仅是缓存数据。如下图所示，代理服务器依据申请的 URL 间接将 HTTP 对应的响应头及响应音讯体返回，流程简洁且高效。

02. 流量分层设计

流量分层次要体现在对于 CDN 层、反向代理层、后端服务层以及数据层流量进行管制。

1）CDN 层流量管制

由动静拆散技术能够想到：应尽量将尽可能多的数据提前生成，而后将其放入 CDN 节点缓存中（因为 CDN 层在物理架构上离用户比拟近）。

所以，如果绝大部分的流量都在这一层获取数据，则达到后端的流量会缩小很多，如下图所示。

2）反向代理层流量管制

在动静拆散计划中，讲到通过“页面动态化技术”减速动态数据的获取，即提前将动态数据生成好，而后对其进行动态化解决。

所以，这里就能够根据页面动态化减速技术，通过后端服务 Job 的形式定时提前生成前端须要动态的数据；而后，将其发送到内容散发服务上；最初，散发服务会将这些动态化页面数据散发到所有的反向代理服务器上，如下图所示。

在“秒杀”业务中，流动详情页上有一个倒计时的模块，用户能够看到以后“秒杀”流动还残余多少工夫开始。

这种逻辑简略的性能能够间接应用 Nginx 来实现：利用 nginx-lua 插件，应用 lua 脚本获取以后 Nginx 服务器的工夫进行计算倒计时。

另外，商品库存数据也能够通过 Nginx 间接拜访分布式缓存来获取，如下图所示。

“秒杀”业务中的商品价格很低，对于用户有很大的吸引力，所以可能会有人利用“秒杀器”进行不公平竞争，且有可能存在竞争对手歹意刷申请的状况。

如果存在这样的状况，那本次流动就是有危险的，万一被歹意流量独占了库存，则会导致失常用户不能抢购商品，也有可能这种歹意的申请会对后端系统造成重大冲击，甚至造成后端系统瘫痪。

对于这种歹意申请，最好有一套机制能提前感知，并将歹意申请提前封存。能够在 Nginx 层中管制；也能够在 Nginx 中配置用户的拜访频率（例如每分钟只能拜访 10 次）；还能够应用 Lua 脚本编写一些简略业务逻辑的接口，例如，通过调用接口间接封掉指定 IP 地址或 UserAgent 的申请。

3）后端服务层流量管制

对于服务层的流量管制，有以下几点倡议：

• 在程序开发上，代码独立，不要与平台其余我的项目一起。
• 在部署时，利用独立部署，扩散流量，防止不适合的流量影响主体业务。
• 应用独立域名，或者依照肯定的 URL 规定在反向代理层进行路由。
• 做好零碎爱护和限流，进一步缩小不必要的流量。

当“达到零碎中的申请数”显著大于“零碎可能解决的最大申请数”时，能够间接回绝这些多余的申请，间接返回“秒杀”流动完结的信息。例如，流动开始时的商品库存是 100，目前库存只剩 50 了，如果“每台服务器待处理的申请数”曾经超过“商品总库存数（100）”了，则能够间接终止掉多余的申请。

4）数据库层流量管制

对于申请到数据中的流量，写入的流量就是真正下单胜利的流量，即须要扣减库存的动作。有如下倡议：

• 如果不是长期的流动，则倡议应用独立的数据库作为“秒杀”流动的数据库。
• 将数据库配置成读写拆散。
• 尝试去除行锁。

对于数据库行锁的优化，能够通过将商品进行拆分来实现——减少 ID，如下图所示。对于繁多的“秒杀”流动这会失去显著效果。

从流量分层管制计划可看出，刹时流量就像被漏斗过滤了似的，应尽量将数据和申请量一层一层地过滤掉。这种流量分层管制核心思想：在不同的层级中尽可能地过滤掉有效的申请，达到“倒三角”最末端的申请才是无效的申请。

5）高可用

在零碎设计时想要做到高可用，防止单节点的一个小妙招：将服务无状态化。如果无奈齐全无状态化（如存储系统），则能够通过冗余多个备份节点的计划来防止单节点。

03. 扣减库存设计

因为在“秒杀”场景中商品个别优惠力度很大，对用户很具备吸引力，所以，在这种场景中应用“下单扣库存”形式更为适合。

在“秒杀”场景中，大部分用户抱着“抢到就是赚到”的想法，根本都会去付款的，但如果真有竞争对手歹意下单不付款，那咱们该怎么办？后面在流量管控中曾经说到，能够对申请日志进行实时剖析，让风控系统抉择出歹意用户，而后将其封停。

在“秒杀”场景中，通过流量分层管制能够分层管控大量的“读”申请。然而，仍然会有很大的流量进入真正的下单逻辑。对于这么大的流量，除后面说的数据库隔离外，还须要进一步优化库存，否则数据库读 / 写仍然是零碎的瓶颈。

接下来看看如何优化大流量“秒杀”场景中的库存数量扣减操作。

1）利用缓存技术

在“秒杀”场景中，如果只是一个扣减库存数量这样的简略流程，则能够先将库存数量间接放在缓存中，而后用分布式缓存（如 Redis）的超高性能去应答这种刹时流量洪峰下的零碎挑战。

应用缓存是存在肯定危险的，比方，缓存节点呈现了异样，那库存数量该怎么算？

应用缓存，不仅要思考分布式缓存高可用（如何设计能够查看我的新书“高并发零碎实战派”），还要思考各种限流容错机制，以确保分布式缓存对外提供服务。

2）异步解决技术

如果是简单的扣减库存（如波及商品信息自身或株连其余零碎），则倡议应用数据库进行库存数量的扣减，能够应用异步的形式来应答这种高并发的库存的更新。

①在用户下单时，不立即生成订单，而是将所有订单顺次放入队列。

②下单模块根据本身的处理速度，从队列中顺次获取订单进行“下单扣库存”操作。

③在订单生成胜利后，用户即可进行领取操作了。

这种形式是针对“秒杀”场景的，根据“先到先得”准则来保障偏心公正，所有用户都能够抢购，而后期待订单解决，最初生成订单（如果库存有余，则生成订单失败）。

这样的逻辑，对用户来说体验不是很差。

具体排队逻辑如下图所示。

4. 搭建千万级流量“秒杀”零碎须要哪些技术

后面介绍了千万级流量“秒杀”零碎的根本架构、“秒杀”零碎的设计准则、如何做动静拆散计划和流量管制，以及扣减库存方面内容。这些都是设计高并发“秒杀”零碎必须要思考的。

“秒杀”零碎的流程并不简单——只是一个“下单扣库存”的动作，但因为其独特的业务特点，所以在进行零碎设计时不能粗心。对于刹时流量洪峰的高并发“秒杀”零碎，咱们须要什么技术呢？上面来总结一下。

（1）数据的动态化的技术

用来应答高并发读的申请，次要波及以下内容：

• 各层级缓存的解决（即多级缓存的技术）
• 分布式缓存技术

（2）负载平衡反向代理技术

• LVS
• Nginx

（3）异步解决技术

• 音讯队列技术
• 排队零碎技术

（4）零碎架构设计技术

• 零碎模块化划分
• 微服务架构思维

（5）系统监控技术

• 日志监控
• 服务监控