字节一面：你负责的业务系统，流量突然提升100倍QPS，你怎么办？

前言

大家好，我是田螺。

分享一道字节面试场景题：假设你负责的业务系统，流量突增，比如QPS暴增100倍，你要怎么处理？

有些伙伴一听完题目，就不假思索回答，那就加机器呀、扩容什么的。当然，这个不能算错，但是你只得其中一小点的分数，肯定不及格的。

作为一名优秀的后端开发程序员，我们应当从多个维度去思考这个问题，尽可能回答完整、正确。

紧急响应阶段：快速止血
冷静分析：为什么？暴增的流量合理嘛
健壮设计，增强系统身体素质
压力测试，测试系统抗压能力

1.紧急响应阶段：快速止血

如果我们负责的系统，突发流量洪峰来了，超过系统的承载能力，为了保护我们的系统，需要快速止血!

1.1 限流

我们可以采取限流方案。其实就是保护系统，多余的请求，直接丢弃。

什么是限流：在计算机网络中，限流就是控制网络接口发送或接收请求的速率，它可防止DoS攻击和限制Web爬虫。限流，也称流量控制。是指系统在面临高并发，或者大流量请求的情况下，限制新的请求对系统的访问，从而保证系统的稳定性。

可以使用Guava的RateLimiter单机版限流，也可以使用Redis分布式限流，还可以使用阿里开源组件sentinel限流。
还可以通过令牌桶、漏桶算法限制请求速率，丢弃超出阈值的请求，避免系统过载。

令牌桶算法：系统以固定速率向桶中添加令牌，请求需获取令牌才能被处理。若桶空则触发限流。
漏桶算法：请求像水一样流入漏桶，桶以恒定速率出水（处理请求）。桶满则溢出触发限流。

1.2 降级熔断

熔断降级是保护系统的一种手段。当前互联网系统一般都是分布式部署的。而分布式系统中偶尔会出现某个基础服务不可用，最终导致整个系统不可用的情况, 这种现象被称为服务雪崩效应。

比如分布式调用链路A->B->C....，下图所示：

如果服务C出现问题，比如是因为慢SQL导致调用缓慢，那将导致B也会延迟，从而A也会延迟。堵住的A请求会消耗占用系统的线程、IO、CPU等资源。当请求A的服务越来越多，占用计算机的资源也越来越多，最终会导致系统瓶颈出现，造成其他的请求同样不可用，最后导致业务系统崩溃。

因此，面对突发激增100倍的流量，我们可以采取熔断降级。

熔断：对非核心服务（如推荐、评论）启用熔断机制（如Hystrix），快速失败以释放资源，优先保障核心链路（如支付、下单）。
服务降级：关闭非关键功能（如数据分析、日志记录），返回兜底数据（如缓存中的默认商品信息），降低后端压力。

1.3 弹性扩容

如果是突发的流量高峰，除了降级、限流保证系统不跨，我们还可以采用这两种方案，保证系统尽可能服务用户请求：

扩容：比如增加从库、提升配置的方式，提升系统/组件的流量承载能力。比如增加MySQL、Redis从库来处理查询请求。
切流量：服务多机房部署，如果高并发流量来了，把流量从一个机房切换到另一个机房。

1.4 消息队列，削锋

我们搞一些双十一、双十二等运营活动时，需要避免流量暴涨，打垮应用系统的风险。因此一般会引入消息队列，来应对高并发的场景。

假设你的应用系统每秒最多可以处理2k个请求，每秒却有5k的请求过来，可以引入消息队列，应用系统每秒从消息队列拉2k请求处理得了。

跳板机会>>>技术大厂，前后端测试，待遇还可以~

2.冷静分析：为什么？暴增的流量是否合理？

面对突发流量，我们得思考清楚，这个QPS来源是否合理呢？

到底是因为双十一、双十二这些促销活动，还是因为一些异常的流量呢（比如代码产生的bug呀，或者是恶意攻击等等）

我们得分析日志、监控等，如果是bug，得评估影响范围，快速修复。
如果是恶意攻击，我们得限制IP、加入黑名单、风控拦截等等。
如果是正常的促销活动，我们得分析流量暴增的范围、时间，比如单个接口还是所有接口呢？分析系统瓶颈是否符合压测的指标（ CPU/内存/磁盘等等），确认是否要采取紧急处理。

3. 设计阶段：健壮设计，增强系统身体素质

回到设计阶段，我们如何避免这些突发的流量倍增呢？

3.1 分而治之，横向扩展

如果你只部署一个应用，只部署一台服务器，那抗住的流量请求是非常有限的。并且，单体的应用，有单点的风险，如果它挂了，那服务就不可用了。

因此，设计一个高并发系统，我们可以分而治之，横向扩展。也就是说，采用分布式部署的方式，部署多台服务器，把流量分流开，让每个服务器都承担一部分的并发和流量，提升整体系统的并发能力。

3.2 微服务拆分（系统拆分）

要提高系统的吞吐，提高系统的处理并发请求的能力。除了采用分布式部署的方式外，还可以做微服务拆分，这样就可以达到分摊请求流量的目的，提高了并发能力。

所谓的微服务拆分，其实就是把一个单体的应用，按功能单一性，拆分为多个服务模块。比如一个电商系统，拆分为用户系统、订单系统、商品系统等等。

3.3 分库分表

当业务量暴增的话，MySQL单机磁盘容量会撑爆。并且，我们知道数据库连接数是有限的。在高并发的场景下，大量请求访问数据库，MySQL单机是扛不住的！高并发（流量倍增）场景下，会出现too many connections报错。

因此，应对流量激增的场景，需要考虑拆分为多个数据库，来抗住高并发的毒打。而假如你的单表数据量非常大，存储和查询的性能就会遇到瓶颈了，如果你做了很多优化之后还是无法提升效率的时候，就需要考虑做分表了。一般千万级别数据量，就需要分表，每个表的数据量少一点，提升SQL查询性能。

3.4 池化技术

在高并发的场景下，数据库连接数可能成为瓶颈，因为连接数是有限的。

我们的请求调用数据库时，都会先获取数据库的连接，然后依靠这个连接来查询数据，搞完收工，最后关闭连接，释放资源。如果我们不用数据库连接池的话，每次执行SQL，都要创建连接和销毁连接，这就会导致每个查询请求都变得更慢了，相应的，系统处理用户请求的能力就降低了。

因此，需要使用池化技术，即数据库连接池、HTTP 连接池、Redis 连接池等等。使用数据库连接池，可以避免每次查询都新建连接，减少不必要的资源开销，通过复用连接池，提高系统处理高并发请求的能力。

3.5 使用缓存

无论是操作系统，浏览器，还是一些复杂的中间件，你都可以看到缓存的影子。我们使用缓存，主要是提升系统接口的性能，这样流量激增的高并发场景，你的系统就可以支持更多的用户同时访问。

常用的缓存包括：Redis缓存，JVM本地缓存，memcached等等。就拿Redis来说，它单机就能轻轻松松应对几万的并发，你读场景的业务，可以用缓存来抗高并发。

3.6 异步

回忆一下什么是同步，什么是异步呢？以方法调用为例，它代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。

因此，设计一个应对激增流量的高并发系统，需要在恰当的场景使用异步。如何使用异步呢？后端可以借用消息队列实现。比如在海量秒杀请求过来时，先放到消息队列中，快速响应用户，告诉用户请求正在处理中，这样就可以释放资源来处理更多的请求。秒杀请求处理完后，通知用户秒杀抢购成功或者失败。