阿里面试：10Wqps高并发，具体 的 “限流阈值” 怎么 计算 ？

本文 的 原文 地址

原始的内容，请参考 本文 的 原文 地址
本文 的 原文 地址
尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

10wqps 限流 阈值，是怎么计算出来的？
你们项目中，怎么限流的？

前段时间小伙伴面试阿里，遇到这个问题。  小伙伴没有准备好，  面试挂了。
问题说明：

限流这项技术，看似简单，实则涉及到算法理论选择与复杂工程落地之间的大量细节与权衡。
记住，当被问及限流时，千万别只停留在背诵算法层面。
45岁老架构师  尼恩提示：
要主动把话题引向阈值的科学计算方法论，向面试官展示你如何结合流量预估、压力测试、  监控数据、  自适应动态调整等多种手段，来解决一个现实的复杂工程难题。
这正是展现你技术深度、让你与众不同的关键所在。
限流：是大厂面试、高P面试的核心面试题

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请到文末《技术自由圈》公号获取

为什么要限流

简单来说：
限流在很多场景中用来限制并发和请求量，比如说秒杀抢购，保护自身系统和下游系统不被巨型流量冲垮等。
以微博为例，例如某某明星公布了恋情，访问从平时的50万增加到了500万，系统的规划能力，最多可以支撑200万访问，那么就要执行限流规则，保证是一个可用的状态，不至于服务器崩溃，所有请求不可用。
限流的思想

在保证可用的情况下尽可能多增加进入的人数，其余的人在排队等待，或者返回友好提示，保证里面的进行系统的用户可以正常使用，防止系统雪崩。

日常生活中，有哪些需要限流的地方?

像我旁边有一个国家景区，平时可能根本没什么人前往，但是一到五一或者春节就人满为患，这时候景区管理人员就会实行一系列的政策来限制进入人流量，
为什么要限流呢?
假如景区能容纳一万人，现在进去了三万人，势必摩肩接踵，整不好还会有事故发生，这样的结果就是所有人的体验都不好，如果发生了事故景区可能还要关闭，导致对外不可用，这样的后果就是所有人都觉得体验糟糕透了。
一、限流的核心三要素

在探讨“阈值计算”之前，必须确保基础知识足够扎实。一切高阶的优化都源于对底层原理的深刻理解。限流的知识体系可以归纳为三个核心要素：
(1) 限流算法：用什么方法来限制流量？
(2) 限流对象：限制谁的流量？限制哪个维度的流量？
(3) 限流后的应对策略：被挡住的请求该怎么办？
简而言之，限流就是通过主动控制进入系统的流量规模，来保护后端服务不被压垮。它尤其擅长应对那些意料之外的流量洪峰。无论是来自外部的恶意攻击，还是内部因异常（如缓存大面积失效）引发的流量激增，限流都是守护系统稳定运行的第一道也是极为重要的防线。
1、核心限流算法

主流的限流算法主要有四种：计数器算法、滑动窗口算法、漏桶算法、令牌桶算法。具体细节会在文章末尾详细说明。
(1) 计数器算法 (固定窗口)

• 原理： 在一个固定的时间窗口内，记录请求数量。当请求数超过预设阈值时，后续请求在该窗口剩余时间内会被限流。
  
• 特点：实现简单。但存在窗口边界突发流量问题（窗口开始时涌入大量请求）。
  

(2) 滑动窗口算法

• 原理： 将时间线划分为更细粒度的子窗口。随时间推移，窗口向前滑动。统计当前滑动窗口覆盖的所有子窗口内的请求总和，如果超过阈值则限流。
  
• 特点： 对固定窗口算法的改进，能更平滑地处理流量，减少边界突刺效应。
  

(3) 漏桶算法

• 原理： 想象一个固定容量的桶，底部有个漏水口以恒定速率漏水（处理请求）。请求到达时像水滴一样进入桶中。如果桶满了（超过容量），多余的请求就会溢出被丢弃。
  
• 特点： 强制以恒定的平均速率处理请求，无论流量多么突发（平滑输出），突发流量会被丢弃或等待。
  

(4) 令牌桶算法

• 原理： 想象一个固定容量的桶，系统以恒定速率往桶里放入令牌。请求到达时，需要从桶中拿走一个令牌才能被处理。如果桶中没有令牌，则请求被限流。令牌桶允许一定量的突发流量（桶里积攒的令牌用完之前）。
  
• 特点： 既能限制平均速率，又能允许短时间内的突发流量（取决于桶容量），对临时流量高峰更友好。
  

2、限流对象

选定了算法，接下来需要清晰地定义限流的作用对象是谁。

从部署维度看

1）单机限流： 限流逻辑仅在单个服务实例内部生效。

• 优点： 实现简单、无外部依赖、性能开销低。
  
• 局限： 无法对整个集群的总流量进行精确控制（每个节点独立计数）。
  

2）集群限流： 需要一个中心化的组件来统计整个集群的流量信息。

• 常见实现： Redis（利用其高性能的原子操作，如 INCR/Lua 脚本）。
  
• 网关集成： 如果限流逻辑部署在 网关层（如 Nginx, Spring Cloud Gateway, Kong, Envoy），网关节点本身就可以充当这个“中心节点”，避免了对外部存储（如 Redis）的额外依赖。
  

从业务维度看

• 按用户身份 (User)： 例如，对 VIP 用户不限流或放宽限制，对普通用户的访问频率进行严格控制。常用于差异化服务。
  
• 按 IP 地址 (IP)： 经典的防 DDoS 和反爬虫手段。例如，对登录、注册、秒杀等关键接口，限制单个 IP 单位时间内的请求次数。通常设置一个合理的上限（如 50 次/秒），能有效过滤掉自动化程序产生的海量请求，同时不影响真实用户（即便是共享出口 IP）。
  
• 按业务 ID (Resource)： 例如，针对特定的 userId、productId、orderId 或某个 API 路径进行限流。防止单个用户滥用、针对特定商品资源请求过多或热点 API 被刷爆，确保资源的公平使用和系统稳定性。
  

3、限流后的应对策略

当一个请求被判断需要限流时，我们并非只能简单地返回一个错误。
设计恰当的处理策略，同样能体现系统的健壮性和用户体验优化。

1）直接拒绝/友好提示：
最常用、最简单的策略  是 直接拒绝/友好提示。
直接向客户端返回一个预设的错误码（如 HTTP 429 Too Many Requests）,  或返回一个  包含友好提示信息的错误响应（如“操作过于频繁，请稍后再试”）。
2）同步阻塞等待：
适用于超出阈值不多的情况（例如，限流 100 QPS，来了 101 个请求）。
让超出的这个请求等待极短时间（如几十毫秒），以获取下一时间窗口/新令牌的机会。
关键点： 必须设置严格的超时时间！
避免无限期阻塞耗尽服务器线程资源，导致雪崩。
3）同步转异步（削峰填谷）：
对于被限流的请求，将其处理逻辑转变为异步。
立即告知用户“请求已接受，正在排队处理”（如返回 HTTP 202 Accepted）。
将该请求信息放入消息队列（如 RabbitMQ, Kafka）持久化。
在系统负载较低时，由后台消费者从队列中拉取任务进行处理。这与服务降级中的“异步处理”理念一致。
4）联动负载均衡：
当某个服务节点频繁触发限流，表明该节点可能已负载过高或存在性能问题。
可以将此信号（如通过健康检查接口、指标上报）反馈给上游的负载均衡器（如 Nginx Upstream, Service Mesh）。
负载均衡器可以据此动态降低该节点的权重，减少后续分配到此节点的流量。

• 注意： 这不是熔断（熔断是彻底切断流量），这是更柔和的、保护性的降级（Degradation）。
  

二、限流阈值 怎么算？

铺垫了足够的基础知识，现在让我们直击核心：当面试官问你“限流阈值怎么定”时，他想考察什么？
他想听到的，绝不应该是“凭感觉”、“拍脑袋”或者“领导定的数”。
他真正期待的是你是否掌握了一套科学、系统的方法来解决这个至关重要的工程问题。
实践中，确定阈值主要有四种思路，其准确性和科学性通常依次递减：压力测试、观测监控、参考借鉴、手动估算。

1、单体服务 估算

首先是 单体服务的预估。  手动估算  核心服务 核心路径的关键步骤及平均耗时。
例如一次请求可能包含：

• 1 次 RPC 调用： ~20ms
  
• 2 次 Redis Get： 每次 ~1ms (2ms)
  
• 1 次带索引的 DB 查询（可能回表）： ~10ms
  
• 业务逻辑处理 + 序列化/反序列化： ~8ms
  
• 单次请求总计： ~40ms
  

据此估算单机理论处理能力：

• 单核 1秒 (1000ms) 处理请求数： 1000ms / 40ms = 25 个请求
  
• 4核机器理论 QPS： 25 * 4 = 100 QPS
  

1. // 简化的理论容量估算公式 (忽略很多现实因素)
3. (1000ms / 预估单请求耗时ms) * CPU核心数 = 理论QPS上限

复制代码

务必强调此方法的严重不足：

• 估算模型非常粗糙！忽略了 JVM GC、IO 阻塞、锁竞争、上下文切换、网络抖动等大量现实开销。
  
• 计算结果必须再乘以一个比较大的折扣系数（如 50% - 60%），得出一个非常保守的初始阈值（如 100 * 60% = 60 QPS）。
  

这只能是临时阈值计算方案，后期必须尽快通过压测或监控数据进行校准！
2、全链路  吞吐量 评估

比较关键的关键的问题来了：
假设你的项目的用户量有百万级，然后每天有几千万请求，高峰期每秒有好几千请求。
全链路  会有多高的QPS？
按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

• 公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
  
• 机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
  

1、每天300w PV   ，全链路  吞吐量 评估  是 多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
2、如果一台机器的QPS是60 ，需要几台机器来支持？
139 / 60  = 3
3、压力测试（黄金标准）

这是确定服务容量和限流阈值的最可靠方法，是严谨工程实践的体现。
面试时，可以这样阐述：
科学确定限流阈值的核心方法是压力测试，目标是找到服务的‘性能拐点’。
首选方式是全链路压测，因为它最接近线上真实复杂的调用链路和资源竞争情况，结果最具参考价值。
若条件有限，至少要在预发布环境或与线上配置一致的独立环境里，对目标服务进行单节点压测。
紧接着，需要清晰解释如何分析压测结果。
建议描述（或手绘/脑补）下方这个经典的性能曲线图：

“压测时，我们逐步增加施压的 QPS（横轴），同时密切关注三个关键指标（纵轴）：响应时间 (Latency)、吞吐量 (Throughput)、资源利用率 (CPU/Memory)。
通常会得到类似上图的关联曲线。”
“从曲线中，我们能识别出几个关键点位：”

• A 点（最佳性能点）：在此点之前，响应时间基本稳定或略微上升，系统资源利用率健康。此时请求能被高效处理，用户体验最佳。
  
• C 点（最大吞吐点）：此时系统达到它能处理的绝对峰值请求量 (Throughput Max)。超过此点，由于资源争抢加剧（如线程、锁、连接池），吞吐量不增反降。
  
• B 点（崩溃临界点）：响应时间急剧飙升，系统资源趋于耗尽（如 CPU 100%），极不稳定，随时可能彻底宕机。
  

那么，限流阈值设在哪一点？
这需要根据业务目标做权衡：

• 追求极致用户体验（低延迟）： 应选 A 点附近的 QPS 值作为阈值（较保守）。牺牲部分吞吐量，确保每个请求都能快速响应。
  
• 追求最大吞吐量（如后台批处理）： 可选 C 点对应的 QPS（较激进）。此时延迟可能较高，但系统处理能力达到极限。
  
• 大多数常规在线服务： 常在 A 点和 C 点之间选择平衡点。最常用的是以 C 点 QPS 乘以一个安全系数 (如 80% - 90%) 作为阈值，为系统预留缓冲空间。
  

告诉面试官， 压测是保障性能和可用性的基石，是技术成熟的标志。
缺乏压测数据支撑，容量规划、性能优化、成本控制都可能失准。
4、线上的 观测监控

压测是理想状态 ，线上 数据 才是 最真实的 。
如果 峰值 QPS 是 1000，且此时资源利用率（如 CPU 70% / Mem 60%）健康，初步可将集群阈值设为 1200（1000 的峰值 + 200 Buffer），为增长和波动留出余量。”
当然， 线上的峰值不等于系统极限！
很可能你的服务实际能承受 3000 QPS，但因业务规模原因没达到过，导致阈值设得过于保守 (1200)，有可能造成资源浪费。
如果进行 线上的 观测监控 ， 请参见 尼恩之前的文章：
高频面题： 你们线上 QPS 多少？你 怎么知道的？
5、限流阈值  的自适应

确定限流阈值 是一个持续迭代的工程活动。
由于平台 篇幅限制， 此处省略  1000字+
原始的内容，请参考 本文 的 原文 地址
本文 的 原文 地址

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除