限流：基于请求限流与基于资源限流的对比，及阈值确定难点

[[降级：丢车保帅的核心思想，及两种实现方式的取舍]]是从系统功能优先级角度应对故障，限流则是从用户访问压力角度应对——只放行系统能扛住的访问量，超出部分直接丢弃，虽然”丢弃”这个词听起来不太友好，但能保证一部分请求正常响应，总比全部请求都扛不住要好。限流常见分两类。基于请求限流是从外部访问角度限制，又分两种：限制总量（限制某个指标的累积上限，如某直播间总用户数上限100万、某抢购活动参与用户上限1万）和限制时间量（限制一段时间内某指标的上限，如1分钟内只放10000用户访问）；实现简单是共同优点，但共同的痛点是很难找到合适的阈值——可能设了1分钟10000用户，实际6000用户系统就扛不住了，也可能到了10000这个阈值时系统压力其实还很轻松就已经开始拒绝新用户了；而且硬件差异也会干扰阈值判断，一台32核机器和一台64核机器处理能力差别很大，但不能简单按核数做线性换算——64核相比32核，业务处理性能可能只是1.5倍甚至1.1倍，不是想当然的2倍。基于资源限流则是从系统内部出发，找到真正影响性能的关键资源（连接数、文件句柄、线程数、请求队列等）、限制其使用上限——比如用Netty实现的服务器给请求队列设个最大长度10000、满了就拒绝后续请求，或者CPU占用率超过80%就开始拒绝新请求；相比基于请求限流，基于资源限流能更真实地反映当前系统的实际压力，但同样面临两个难点：如何确定该盯住哪个关键资源、如何确定这个资源的合理阈值。两类限流的阈值确定都不是一次到位的事，通常都要经过”先按推断/性能压测定一个初始值→上线观察运行情况→发现不合理再调优”这个反复迭代的过程；基于请求限流因为逻辑相对简单，更适合功能比较单一的系统（负载均衡系统、网关系统、抢购系统这类）。

结构图：

flowchart TB
  A["限流：只放行系统能承受的访问量"]
  A --> B["基于请求限流(外部视角)"]
  B --> B1["限制总量：如直播间总用户数上限"]
  B --> B2["限制时间量：如每分钟访问量上限"]
  B1 --> B3["痛点：阈值难定+硬件差异不能线性换算<br/>适合功能简单的系统(网关/抢购系统)"]
  B2 --> B3
  A --> C["基于资源限流(内部视角)"]
  C --> C1["盯关键资源：连接数/文件句柄/线程数/请求队列<br/>如CPU占用超80%拒绝新请求"]
  C1 --> C2["更真实反映系统压力<br/>但难点在于选对资源+定对阈值"]
  B3 --> D["阈值确定都需迭代：<br/>推断/压测→上线观察→调优"]
  C2 --> D