并发数限流和 QPS 限流有什么区别？

简化版

QPS 限流限制单位时间内进入的请求数量，并发数限流限制同一时刻正在处理的请求数量。QPS 适合控制入口速率，并发数适合保护线程池、连接池、下游慢调用等有限资源，两者经常配合使用。

详细版

区别如下：

维度	QPS 限流	并发数限流
控制对象	单位时间请求数量	同时执行中的请求数量
关注点	流量速率	资源占用
典型算法	令牌桶、窗口计数	信号量、线程池、舱壁隔离
适合场景	API 入口、用户额度	慢接口、下游连接、数据库操作

如果接口非常快，较高 QPS 也未必占用太多资源；如果下游变慢，即使 QPS 不高，并发也可能堆满线程池。因此只做 QPS 限流不一定能防止慢调用拖垮系统，并发数限制可以直接保护资源占用。

完整版教学

一、QPS 和并发不是同一个指标

QPS 表示每秒处理多少请求，并发数表示某个时刻有多少请求正在处理中。二者之间和响应时间有关，可以粗略用 Little 定律理解：

并发数 ≈ QPS × 平均响应时间

如果一个接口 100 QPS，平均耗时 10ms，同时在处理的请求大约 1 个；如果平均耗时变成 1s，同时在处理的请求大约 100 个。QPS 没变，但资源占用增加了 100 倍。

这就是为什么下游变慢时，系统会被拖垮。流量没有变大，但请求处理时间变长，线程、连接、内存都被占住，并发数上升，最终队列堆积。

二、QPS 限流适合控制入口速率

QPS 限流适合回答“每秒最多让多少请求进来”。比如开放 API 每个用户每秒 100 次，某接口全局每秒 5000 次，某 IP 每分钟 1000 次。这类限制关注速率和公平性。

入口 QPS 限流能把过量流量挡在系统外，减少后端压力。它通常放在网关、服务入口或 SDK 中。算法可以用令牌桶、固定窗口、滑动窗口。

但 QPS 限流对请求耗时不敏感。一个接口平时 50ms，某天数据库慢到 3s，原来的 QPS 阈值可能已经不安全了。此时还需要并发数限制、超时和熔断配合。

三、并发数限流适合保护有限资源

并发数限制常用信号量实现。请求进入前先获取许可，处理完成后释放许可。许可数量就是最大并发数。如果拿不到许可，请求可以拒绝、排队或降级。

伪代码可以这样理解：

if semaphore.tryAcquire():
  try:
    handleRequest()
  finally:
    semaphore.release()
else:
  rejectOrFallback()

它特别适合保护线程池、连接池、下游接口、数据库慢操作、文件导出等资源。比如某个第三方接口最多承受 50 个并发调用，即使 QPS 不高，也要限制同时调用数量，避免把对方或自己拖死。

四、并发限流要小心排队

拿不到并发许可时，有些系统会让请求排队。但排队不是无限安全的。队列太长会增加响应时间，占用内存，也会让用户等待后仍然超时。更糟的是，客户端超时后重试，旧请求还在队列里，新请求又进来，形成堆积。

因此并发限流通常要配合短队列或不排队策略。核心接口可以少量排队，非核心接口快速失败。队列等待时间要有上限，超过就拒绝。服务端拒绝要比让请求无意义等待几十秒更健康。

五、两种限流经常组合使用

一个稳定的接口可能同时设置：入口令牌桶限制 QPS，服务内信号量限制并发，下游调用设置连接池和超时。入口挡住突发流量，并发限制保护处理资源，超时避免请求长期占用资源。

例如订单查询接口平均 50ms，容量评估支持 2000 QPS，同时最多允许 200 个请求在处理。如果数据库变慢，QPS 还没达到 2000，但并发达到 200，就会触发并发限制，防止线程池被拖满。

这说明 QPS 限流保护“进入速度”，并发限流保护“占用数量”。两者不是替代关系。

六、并发数阈值要从资源容量推导

并发数不能随便设置。要看线程池大小、连接池大小、下游最大并发、平均延迟和 P99 延迟。如果数据库连接池只有 100，某接口却允许 500 个并发数据库请求，大量请求会卡在连接池等待，形成无效堆积。

阈值还要分接口。快接口可以较高并发，慢接口要较低并发；核心接口优先保留资源，后台导出或复杂查询要单独资源池。并发限流和线程池隔离、舱壁模式关系很近，都是为了避免一个慢资源拖垮全部请求。

七、面试追问中的常见坑

如果面试官问“QPS 不高为什么系统还挂了”，可以从响应时间变长导致并发堆积回答。下游慢、锁等待、数据库慢查询、GC 暂停都会让请求占用资源时间变长，最终线程池和连接池耗尽。

如果问“并发数限流能不能控制 QPS”，答案是间接控制，不精确。并发固定时，接口越快 QPS 越高，接口越慢 QPS 越低。它保护资源，但不是严格速率限制。

如果问“限流后排队还是拒绝”，要看业务等待价值和资源压力。短暂排队适合削峰，长时间排队会恶化系统，很多场景应该快速失败或异步化。

八、常见误区与追问

这道题要紧扣「并发数限制与 QPS 限制」本身回答，不能把它混成泛泛的流量控制套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明限流位置、算法窗口、阈值来源、拒绝策略、退避降级和观测指标。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	QPS 限制控制单位时间请求量，并发限制控制同时在途请求数，分别保护入口流量和下游资源占用	不要停在名词解释
流程机制	识别保护对象 -> 选择 QPS 或并发阈值 -> 请求进入计数器 -> 超过阈值拒绝或排队 -> 请求结束释放并发 -> 动态调整阈值	要说清触发点、状态变化、确认点和失败兜底
工程取舍	接口平均耗时 200ms，限制并发 100，则稳定吞吐约 100 / 0.2 = 500 QPS	限流保护系统稳定性，但会牺牲一部分请求成功率或响应实时性

并发数限制与 QPS 限制 面试拆解：
1. 识别保护对象
2. 选择 QPS 或并发阈值
3. 请求进入计数器
4. 超过阈值拒绝或排队
5. 请求结束释放并发
6. 动态调整阈值

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「并发数限制与 QPS 限制」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

误区：限流就是简单拒绝请求。 合格答案要区分放行、排队、快速失败、降级、退避和熔断，而不是只说“挡住流量”。
误区：全局平均流量低就没有风险。 热点 key、单实例、单下游资源仍可能先被打满，所以要看局部水位。
误区：限流阈值可以拍脑袋配置。 阈值要来自压测容量、依赖水位、错误率、P99 延迟和业务优先级。
追问：限流应该放在哪里？ 入口网关、服务内部、客户端和下游资源侧可以分层配置，分别保护不同边界。
追问：触发限流后怎么处理？ 核心写请求可排队，非核心读请求可降级，用户侧要给明确失败或稍后重试。
追问：如何验证流控策略有效？ 看 QPS、并发、延迟、拒绝率、队列长度、下游错误率和恢复时间。

九、加强记忆

QPS 限流管“每秒进来多少”，并发数限流管“此刻占着多少资源”。接口变慢时，即使 QPS 不变，并发也会暴涨。入口用 QPS 控速，服务内用并发数保护资源，再配合超时、熔断和隔离，系统才不容易被慢调用拖垮。

简化版

详细版