多级缓存与限流调度

• 缓存行的空间局部性为何行优先更快
• 缓存行失效与伪共享的机制
• 伪共享对多线程吞吐的影响

按行优先遍历二维数组更快，是因为数组按行连续存放，行优先访问时相邻元素在连续内存中，命中同一缓存行（通常 64B），充分利用空间局部性，减少缓存未命中；列优先则每次访问跨越整行，频繁触发缓存行替换，发生大量 CPU 缓存 miss。缓存行失效指多个核共享的缓存行被某一核改写后，其它核的副本失效，需重新获取，造成额外开销。伪共享（false sharing）指两个线程各自访问"不在同一缓存行内的不同变量"但实际上它们却落在同一缓存行上，虽无数据依赖，但任一变量被写都会使整个缓存行失效，导致另一线程反复重新加载，产生缓存抖动，严重降低多线程吞吐。缓解伪共享用缓存行填充（padding）把变量对齐到独立缓存行，或使用按线程隔离的变量。

缓存行是 64B 的原子单元，性能优化的关键是"空间局部性"与"缓存行对齐"。行优先 vs 列优先体现前者；伪共享体现后者在多线程下的隐性开销。面试常考"把两个频繁写的高并发热变量错开缓存行"。

• SFQ 用哈希把流映射到有限队列
• 哈希冲突导致不同流互相干扰的公平性
• 流感知哈希、按流状态、增大队列数

随机公平排队（SFQ）用哈希把大量流映射到少数的队列（如 64 个），每个队列按 FQ 公平调度，从而以低内存实现近似公平。但哈希冲突会让不同流落入同一队列，这些流被当作一个整体排队，互相干扰：一个流突发会挤占同队列其它流的带宽，破坏公平性。降低冲突的手段：用流感知哈希（flow-aware hash，把流特征如五元组结合随机种子哈希，使映射更均匀、降低冲突概率）和使用键控哈希（keyed hash，加入随机盐）；或按流维护状态（为热流单独分配队列，冷流走哈希队列，即"多级队列 + 热流直连"）；或增大队列数减少冲突概率。但完全消除冲突需要每流独立队列，内存成本高，故常用"哈希 + 少量热流特权队列"折中。

SFQ 的本质是"用哈希近似每流公平"以省内存，冲突是其固有代价。核心权衡是"内存 vs 公平性"。流感知哈希降低冲突概率、热流单独队列精确保障热流公平，是工程常用组合。理解"哈希冲突会破坏公平"是本题关键。

• deficit counter 与 quantum 的机制
• 按权重分配带宽且无需排序
• DRR 的 O(1) 复杂度 vs WFQ 的排序复杂度

DRR 维护每个流的 deficit counter 与 quantum（按权重设定的服务量）。每次轮询时，流的 deficit 加上 quantum，然后从该流发出队列头部的包，每发一个包就减去其长度，直到剩余 deficit 不足以发出下一个包为止，然后轮到下一流。这样长期来看每个流获得的带宽与其 quantum（权重）成正比，实现按权重公平分配。关键优点：无需按时间戳/虚拟时间排序，只需循环遍历就绪队列，复杂度 O(1)（每轮流程），远低于 WFQ 需要维护按虚拟完成时间排序的优先级队列（O(log n) 或 O(1) 用折叠队列）。DRR 的缺点是最坏延迟控制不如 WFQ 精确（一个流可能发完整个 quantum 才停），但实现简单、硬件友好，广泛用于交换队列。

DRR 用"deficit 累计 + 按权重发 quantum"替代排序，用"轮询"实现公平，是"以简单换一点延迟精度"的典型。WFQ 通过虚拟时间精确模拟理想 GPS，公平与延迟最优但需排序与虚拟时间计算。DRR 适合需要高吞吐、实现简单的场景。

• inclusive（上级包含下级）与 exclusive（互斥）的定义
• L1/L2 exclusive 的容量利用率
• LLC inclusive 的一致性简化

inclusive 缓存：上级缓存包含所有在下级缓存中的数据（下级数据必在上级的某个副本中存在）；exclusive 缓存：上级与下级的数据互斥，数据只在某一级存在。L1/L2 常做 exclusive，因为这样两级缓存容量相加才等于总容量，避免重复存储浪费空间，提高有效容量；而 LLC 常见 inclusive，因为 LLC 作为最后一层，inclusive 便于一致性维护——CPU 只需检查 LLC 即可知道某行是否在缓存系统中，替换时也容易弄清哪些上级行需要失效，简化多核一致性。inclusive 的优点是一致性简单、cache coherency 易维护，缺点是容量利用率低（重复存储）；exclusive 优点是不重复存储、容量利用率高，缺点是一致性维护复杂（需记住数据在哪个级别）。

包含策略是"容量利用率 vs 一致性简单"的权衡。L1/L2 追求容量（exclusive），LLC 追求一致性简单（inclusive）。现代 Intel 大核常 L1/L2 非严格包含，LLC 采用 inclusive（或非强制包含）以简化 snoop 过滤。理解"inclusive 简化一致性、exclusive 省容量"是核心。

• ECN 在路由器标记（CE）而非丢包
• DCTCP 用 ECN 标记比例估计拥塞程度
• 相比 Reno 的丢包响应，DCTCP 更平滑

ECN（显式拥塞通知）允许路由器在队列接近拥塞时，把包头 ECN 字段标记为 CE（Congestion Experienced）而非丢弃，接收端通过 ACK 告知发送端，从而用"标记"代替"丢包"传递拥塞信号，避免丢包重传的开销。DCTCP 在 ECN 基础上，让发送端统计"被标记包的比例"（近期被标记的包数 / 总包数），用该比例估计拥塞程度，把拥塞窗口减为当前窗口的 (1 - α/2)，其中 α 是标记比例。因此 DCTCP 能根据拥塞程度"渐进"调整窗口，精确控制队列长度保持在很小的缓冲区（避免缓存溢出），同时响应比 TCP Reno 更平滑（Reno 是丢包时窗口减半、线性恢复，抖动大）。DCTCP 适合数据中心低延迟拥塞控制，但依赖交换机 ECN 支持与较高阈值设置。

核心差异是"信号粒度"：Reno 只有"丢包/不丢包"二值信号，DCTCP 用"标记比例"连续估计拥塞强度，从而更平滑地控制窗口与队列长度。ECN 提供"标记而非丢包"的机制，DCTCP 提供"如何利用标记比例"的算法。DCTCP 的 α 是标记比例的指数移动平均，控制拥塞窗口缩放。

• SJF 最小化平均等待时间的证明直觉
• 长作业饿死问题
• SRTF 抢占式与饥饿

SJF 按"运行时间最短优先"调度，其最优性（最小化平均等待时间）可由交换论证：若队列中先运行较长的作业 A 再运行较短的作业 B，等待时间会叠加大作业的时间；交换为先 B 后 A 总能减少平均等待时间，因此最优调度一定按作业长度递增执行。缺陷是"饿死"：若新作业不断插入且都更短，长作业可能永远得不到 CPU；且 SJF 需要知道作业的实际运行时间，现实中只能估计。抢占式 SRTF（最短剩余时间优先）在每个新作业到达时，若其剩余时间小于当前作业剩余时间则抢占，它同样最小化平均等待时间，但加剧了长作业的饥饿——不停有"剩余时间更短"的新作业插入会持续抢占长作业。缓解饥饿可加老化（aging）提高长作业优先级。

核心是"交换论证"理解最优性、以及"短作业优先导致长作业饥饿"。SRTF 是 SJF 的抢占版，最优性相同但饥饿更严重。工程上 SJF 常见于批处理，交互/实时场景需配合老化或优先级。

• BBR 基于 BDP（带宽×RTT）建模
• CUBIC 基于丢包/拥塞窗口
• 浅缓冲 BBR 减少丢包、深缓冲下与 CUBIC 的公平性

BBR 通过测量瓶颈带宽（BtlBw）与最小 RTT，估计 BDP = 带宽 × RTT，把发送速率控制在 BDP 附近，从而在不填满缓冲区的情况下保持高吞吐，避免依赖丢包信号。CUBIC 则基于 AIMD 的拥塞窗口，靠丢包（或 ECN）触发窗口削减，在深缓冲下会持续填满缓冲区造成高排队延迟（bufferbloat）。在浅缓冲链路，BBR 因为不主动填满缓冲区、不触发丢包，吞吐稳定、延迟低，明显优于 CUBIC（CUBIC 会因丢包反复减窗）；在深缓冲链路，BBR 同样能避免 bufferbloat，但 CUBIC 会占满缓冲区从而在"丢包退避"上处于劣势，可能导致 BBR 抢得更多带宽、与 CUBIC 竞争时不太公平（BBR 不主动退让）。BBR 的代价是需稳定测量 RTT 与带宽，多流与 RTT 变化时可能取不到最小 RTT。

本质是"模型驱动"（BBR 用 BDP 建模）vs"信号驱动"（CUBIC 用丢包）的差异。BBR 减少对丢包的依赖，避免 bufferbloat，但公平性（与 CUBIC 共存时）与多路径稳定性是其短板。理解 BDP 与丢包信号的区别是关键。

• CUBIC 用三次函数控制窗口增长
• 凸阶段快速探索、凹阶段接近 Wmax 时慢速
• 大延迟带宽积下的竞争力与公平性

CUBIC 的拥塞窗口随时间按三次函数增长，窗口 W = C(t - K)³ + Wmax，其中 Wmax 是上次丢包时的窗口大小，K 是恢复到 Wmax 所需时间。刚丢包减窗后，窗口离 Wmax 远，处于凸增长阶段（增长快，快速探测可用带宽）；接近 Wmax 时进入凹阶段（增长放缓，在 Wmax 附近维持稳定），从而避免在 Wmax 附近大步探测造成抖动。相比 Reno 的 AIMD（每 RTT 线性加 1、丢包减半），CUBIC 的窗口增长与 RTT 无关（基于时间而非 RTT），且凸阶段增长更快，因此在 BDP 大（高带宽长 RTT）的链路上能更快恢复并利用带宽，吞吐更高。公平收敛性：CUBIC 的凹阶段使不同流在共享瓶颈时收敛到公平分配，但收敛速度与 RTT 无关，多流竞争时收敛行为与 Reno 不同，可能略慢或波动，需通过参数与 RTT 补偿调节。

核心是"三次函数 + 凸/凹切换"：凸段快速利用带宽、凹段在 Wmax 附近稳定，时间驱动摆脱 RTT 依赖，使大 BDP 链路高吞吐。CUBIC 显著优于 Reno 的 AIMD 在长链路的表现，但公平性需与拥塞窗口的收敛动态结合评估。

• 虚拟时间与 finish time 的机制
• 按权重公平分配带宽
• 与严格优先级（SP）在延迟与公平上的差异

WFQ（加权公平队列）为每个包维护一个虚拟完成时间（finish time），它基于虚拟时间（模拟理想流体 GPS 服务）与该流权重计算：finish = 虚拟时间 + 包长度/权重。调度时按 finish time 从小到大出队，从而实现"按权重公平分配带宽"，且能隔离流之间（一个流突发不影响其它流）。相比严格优先级排队（SP，先服务高优先级队列，低优先级仅在高优先级空时服务），WFQ 的优势是带宽公平：低权重的流也能获得应得带宽，不会因高优先级持续存在而饿死；SP 则保证高优先级的最低延迟，但低优先级可能长期得不到服务（饿死）。差异本质：WFQ 用"虚拟时间+权重"实现按比例公平但单个流延迟保障弱于 SP 的绝对优先；SP 牺牲公平换取绝对优先级。实际常两级结合（先 SP 分层，层内 WFQ）。

WFQ 的 finish time 是"按权重公平"的量化实现，复杂度需维护排序队列（O(log n)）。SP 简单但公平性差。理解"带宽公平 vs 延迟优先"的取舍是核心：WFQ 保公平、SP 保绝对优先级。

• Cache-Aside（旁路）与 Write-Through（写穿）的差异
• 击穿（热点过期）与雪崩（大量过期）的治理
• 随机 TTL、互斥重建、永不过期

Cache-Aside：应用先读缓存，miss 再读 DB 并回填缓存；写时先写 DB 再删缓存（或更新缓存），缓存由应用显式管理，读多写少时减少写开销，但需处理"先删缓存后写 DB"的窗口（可能读到旧值）。Write-Through：写操作先写缓存再同步写 DB，保证了缓存与 DB 的一致性，但每次写都双写，写开销大，读性能与 Cache-Aside 相近。避免击穿：热点 key 过期时用互斥重建（只让一个线程回源重建，其余等待或返回旧值），或"热点永不过期 + 后台异步刷新"。避免雪崩：大量 key 同时过期会集中回源 DB，用给 TTL 加随机抖动（分散过期时间）、或热点预加载/多级缓存降级。此外可加布隆过滤/空值缓存防穿透。

Cache-Aside 是工程最常用（延迟写、读多写少），Write-Through 适合强一致或写多场景。击穿/雪崩本质都是"缓存集中在某时刻失效导致回源压力"，分别用"单点互斥"与"TTL 抖动"治理。理解"何时删缓存 vs 何时更新缓存"及"怎么防并发回源"是关键。

• 令牌桶的突发能力与桶容量
• 滑动窗口的平滑与内存成本
• 按业务对突发/平滑的需求选择

令牌桶：以固定速率往桶里加令牌，请求需消耗令牌，桶容量决定允许的突发量（突发可到桶容量大小）。实现简单（O(1) 状态）、允许一定突发（适合突发流量），但瞬时速率可能超过限速（到桶容量）。滑动窗口：记录窗口内请求数，精确平滑流量，能精确控制"任意滑动窗口内不超过 N"，但精确滑动窗口需记录每个请求时间戳（内存/实现成本高），或用量化窗口近似（有边界误差）。选择依据：业务是否允许突发——允许突发（如 API 突发、秒杀前的短时突增）用令牌桶；需要严格平滑、防止瞬时波峰（如对下游 DB 的限流、计费）用滑动窗口；若需平滑又省内存，可用"滑动窗口近似"（多个固定小窗口）或令牌桶+队列缓冲。

核心是"允许突发 vs 严格平滑"的取舍。令牌桶用桶容量表达突发上限，简单高效；滑动窗口精确计数但成本高。选择取决于业务对"瞬时波动"的容忍度与下游的背压能力。

• FQ 按流独立队列、每流公平份额
• 避免某个流饿死其它流
• 令牌桶只限制总量，不区分流

公平队列（FQ）为每个流维护独立队列，调度时让每个流获得大致相等的带宽份额（或按权重），从而避免某个流大量占用带宽而饿死其它流。它提供"流间公平性"。令牌桶则只限制"总速率"，不区分流：无论哪个流用了令牌，只要总量不超限，即使一个流独占所有令牌、其它流被拒，也符合限制。因此令牌桶保证"总量上限"，FQ 保证"流间公平"。差异本质：令牌桶过滤"总量"（防止总流量超限、保护下游），FQ 调节"分配"（防止单个流独占、保证多流公平）。工程上常结合：先令牌桶限总速率，再 FQ 在内部按流公平分配，或对高优先级流加权。

核心是"总量限制 vs 分配公平"的区别。令牌桶回答"总流量是否超限"，FQ 回答"每个流是否公平"。防饿死（一台主机占满带宽）靠 FQ，防击穿下游（总流量超限）靠令牌桶。理解两者目标不同是关键。

• 雪崩/击穿/穿透在各层的传播路径
• 布隆过滤器、空值缓存、互斥重建、随机 TTL
• 多级缓存降级与兜底

级联故障中各层传播：穿透（不存在 key）在缓存层无法命中，直接打到 DB，若恶意大量不存在的 key 会压垮 DB；击穿（某热点 key 过期）在该层 miss 后大量请求同时回源 DB，压垮 DB；雪崩（大量 key 同时过期）使整层缓存同时失效，海量请求瞬间打到 DB，引发 DB 过载甚至级联到更下游。预防手段：穿透用布隆过滤器（先在缓存前判断 key 是否存在）与空值缓存（把不存在结果也短缓存）；击穿用互斥重建（热点过期时单线程重建）、热点永不过期（后台异步刷新）；雪崩用 TTL 随机抖动（分散过期时间）、多级缓存（即使本地失效仍有 Redis）、限流降级与 DB 保护（熔断、限流）。多级缓存下，一级失效由下一级兜底，但需确保不会"各级同时失效"（如都设相同 TTL）。

三个问题的本质都是"缓存 miss 导致 DB 压力集中"，但成因不同：穿透=数据不存在、击穿=单热点过期、雪崩=批量过期。治理要点分别是"过滤不存在"、"保护单热点"、"分散过期时间与多级兜底"。理解传播路径与对症下药是关键。

• SJF 饿死长作业的机制
• 老化提高等待时间长的作业优先级
• 优先级继承解决优先级反转

饿死：SJF 每次优先选择最短作业，若新短作业不断到达，长作业不断被推后，可能永远得不到 CPU，即饿死。老化（aging）缓解：为每等待一个时间单位就给作业优先级 +1，随着等待时间增长其优先级自动提升，最终长作业也能获得 CPU，从而打破饿死。优先级反转：低优先级任务持锁时，高优先级任务等待该锁，而中优先级任务抢占低优先级任务，使高优先级任务被中优先级任务间接阻塞（无界阻塞）。优先级继承解决：当低优先级任务持有高优先级任务需要的锁时，把低优先级任务的优先级临时提升到高优先级任务的水平，从而不被中优先级任务抢占，尽快释放锁，消除无界阻塞（Mars Pathfinder 案例）。

饿死与优先级反转是调度中的两个经典问题。老化对付"等待太久"（SJF 饿死），优先级继承对付"持锁被抢占"（优先级反转）。理解"为什么短作业会饿死长作业"（无限新短作业）与"为什么低优先级会阻塞高优先级"（持锁+中优先级抢占）是关键。

• Redis + Lua 原子执行限流计数
• 原子性（INCR/DECR + EXPIRE 的组合）
• 节点故障时计数丢失如何兜底（本地备份/降级）

多实例网关共享限流状态，把计数器放在 Redis，用 Lua 脚本原子执行"判断-计数-返回"逻辑，避免多实例并发时竞态（如两个请求同时读到未超限）。Lua 脚本在 Redis 单线程执行，保证原子性。典型实现：用 key 存计数，INCR 后若超过阈值则拒绝，并设置/刷新 TTL。节点故障导致计数丢失的问题：若 Redis 主节点故障或计数 key 过期/丢失，限流状态丢失，可能造成短暂的超发。兜底手段：启动时用本地初始化计数器（如按本地份额估算）、Redis 故障时降级为本地限流（如本地令牌桶）或直接放行（fail-open）或拒绝（fail-closed）由策略决定，以及用 Redis 集群/持久化（AOF）减少丢失窗口。核心是"集中计数 + 原子操作 + 故障降级策略"。

分布式限流的难点是"原子性"与"可用性"。Lua 脚本解决原子性（多实例并发计数），故障降级解决可用性（Redis 挂时怎么保证限流仍有效）。设计上要权衡 fail-open（保可用，可能短暂超发）与 fail-closed（保限流，可能误拒）。

• L1/L2/L3 的容量与延迟量级
• 缓存命中/未命中对性能的主导
• 时间/空间局部性优算法胜过理论复杂度

典型量级：L1 每核 32-64KB、延迟约 3-4 周期；L2 每核 256KB-1MB、延迟约 10-15 周期；L3 共享 8-32MB、延迟约 30-80 周期；主存约 100-200 周期。缓存未命中到主存的代价巨大（几十倍于 L1 命中），因此"缓存友好"（局部性好、命中率高）的算法往往比"理论复杂度低但缓存不友好"的算法更快。例如：矩阵乘法用分块（blocking）利用缓存行局部性，比朴素三重循环快得多；二维数组按行优先遍历；链表遍历（缓存不友好）比数组遍历慢。当数据量超过缓存容量，访问模式（是否连续、是否复用）比算法的大 O 复杂度更主导实际性能，因为内存访问延迟是主导瓶颈。

三层缓存是"容量递增、延迟递增"的层级。缓存友好算法的本质是"把访问模式与缓存层级匹配"（空间局部性用满缓存行、时间局部性复用热数据）。现代 CPU 内存访问常是性能瓶颈，因此缓存优化往往比常数优化与大 O 复杂度优化更明显。

• 用 RTT 变化（实际 vs 期望吞吐差）探测拥塞
• 在丢包前就调整窗口，减少排队延迟
• 与 Reno 的公平性问题（新流难获得公平份额）

TCP Vegas 用"期望吞吐（window/最小RTT）与实际吞吐（window/当前RTT）之差"来估计队列中积压的数据量：若实际吞吐低于期望，说明出现排队，据此在丢包发生前就线性调整窗口（增加或减少），从而避免填满缓冲区、减少排队延迟。这与 Reno 的"丢包才减窗"不同——Vegas 在拥塞初现（RTT 变大）时就响应，因此队列更短、延迟更低。问题在于公平性：Vegas 依据 RTT 估计拥塞，而 RTT 中包含传播延迟，导致不同 RTT 的流对"拥塞"的判断不同；且新流与老流竞争时，Vegas 的"谨慎"（在 RTT 增长时提前减窗）使其在启用 Reno 的混合网络中难以获得公平份额——老流已占满，新流感到 RTT 增大就放缓，难以抢到带宽。此外 Vegas 对最小 RTT 的测量敏感，RTT 变化不规律时表现不稳定。

核心是"基于延迟（RTT）的拥塞控制 vs 基于丢包的拥塞控制"。Vegas 用延迟变化提前响应，减少排队延迟，但依赖 RTT 估计导致公平性/稳定性问题。与 Reno 的"丢包信号"相比，Vegas 是"延迟信号"，更早但也更脆。

• BDP = 带宽 × RTT 的物理意义
• 缓冲区小于 BDP 时吞吐受限
• 缓冲过大浪费内存与增大延迟

BDP（带宽×延迟积）是"在途数据量"的上界：一个 ACK 回到发送方需要 RTT 时间，期间发送方要能持续发送，若缓冲区（拥塞窗口上限）小于 BDP，则发送方在等 ACK 时无数据可发，链路利用率下降，吞吐受限（吞吐 ≈ 窗口/RTT）。因此发送缓冲（及接收缓冲）至少应为 BDP 才能跑满带宽。若缓冲过小，吞吐被"窗口限速"；若缓冲过大，则浪费内存，且可能使队列积压、增大延迟（bufferbloat）。权衡：对高 BDP 链路（高带宽 × 长 RTT，如卫星、跨洲）需大缓冲跑满吞吐，但内存代价高；对交互/低延迟场景宁可小缓冲降低延迟。现代内核用自动调优（autotuning）动态调整缓冲区大小，网络拥塞控制（如 BBR）也协调缓冲区与 BDP。

BDP 是"吞吐=窗口/RTT"的直接推论。理解"窗口必须 ≥ BDP 才能填满管道"是关键。缓冲大小是"吞吐 vs 内存/延迟"的权衡，自动调优平衡两者。

• 令牌桶的桶容量表达突发
• 漏桶固定速率输出强制平滑
• 各自适用场景

令牌桶：以固定速率向桶中加令牌，桶有容量上限（对应允许的最大突发量），请求需消耗令牌，桶中有令牌即可放行。因为空闲时令牌积累，突发时可用积攒的令牌，因此允许突发到桶容量。漏桶：是一个固定容量、固定出口速率的桶，请求以恒定速率流出，无论输入多快，输出速率恒定，从而强制平滑、消除突发。实现上令牌桶用一个计数器+时间戳维护（O(1)），漏桶用队列+定时器（需缓冲或直接按固定速率处理）。适用场景：令牌桶适合"允许一定突发、整体速率受控"的业务（如 API 网关、峰值突发较快的场景）；漏桶适合"必须严格平滑输出、防止凌波突刺"的场景（如限速下游、流量整形、平滑数据库写入）。

核心区别是"输出速率是否可变"。令牌桶输出速率可变（可突发到桶容量），漏桶输出速率恒定（强制平滑）。选择取决于业务是否允许突发：允许突发用令牌桶，必须平滑用漏桶。

• Redis 集中计数精确但每次请求有网络成本
• 本地令牌桶+定期配额低延迟但有超发窗口
• 超发窗口与降级策略设计

Redis 集中计数：所有实例共享一个计数器，限流状态全局一致，精确，但每次请求都访问 Redis（有网络往返，延迟与成本高，高并发下还可能在 Redis 形成热点）。本地令牌桶+定期配额同步：每个实例维护本地令牌桶，从中央配额定期（如每 100ms-1s）同步一次可用的配额，请求只在本地判断，延迟极低、无 Redis 热点；代价是同步间隔内配额是"估算"，可能超发（超发窗口 = 同步间隔），且实例数×配额分配需权衡（均分或按需拉取）。超发窗口设计：把同步间隔设小以降低超发量，或允许"在配额内突发、超配额拒绝"；降级策略：Redis 故障时降级为本地限流（按本地份额）或 fail-open（放行）+ 告警，保证限流不失效也不误杀。成本与精度权衡：高并发、可容忍轻微超发用本地+配额同步；精确严格限流（如计费）用 Redis 集中计数。

本质是"精度 vs 成本"。集中计数精确但贵、有热点；本地配额快但近似、有超发窗口。工程上常混合：一般限流用本地配额，关键精确限流用集中计数，并设计故障降级。

• TCP 窗口、队列积压、应用限流的逐级反馈
• 背压的本质是"上游感知下游能力"
• 缺背压导致内存溢出与重试风暴

背压（backpressure）是"下游处理能力反馈给上游，限制上游发送速率"的机制。逐级实现：TCP 用接收窗口（rwnd）告知发送方可接收的数据量，发送方据此限速；队列层用有界队列，队列满时拒绝新请求或阻塞生产者；应用层限流用信号量/并发限制器控制同时处理的请求数。当下游处理慢时，逐级反馈使上游放缓，形成端到端的负反馈。若缺少背压：下游处理跟不上，请求在缓冲/队列中无限堆积，导致内存溢出（OOM）；或请求超时后客户端重试，重试又加剧下游负载，形成"重试风暴"（retry storm），进一步压垮系统。因此用有界队列、信号量、TCP 窗口、限流等逐级背压，是保障系统稳定性的关键。

背压的本质是"能力感知与限速"。逐级反馈（TCP→队列→应用）让整个链路协同，避免"下游已过载仍持续发送"。缺少背压的后果（内存溢出、重试风暴）说明"无限缓冲"与"无限重试"是有害的。理解"有界资源 + 负反馈"是核心。

• 用线程利用率/排队延迟估计系统负载
• 动态调整并发控制上限
• 过载时快速失败（fail fast）而非排队

自适应限流根据系统实时负载动态调整"允许并发数"上限。典型指标：线程利用率（CPU/线程池利用率）与排队延迟（请求在队列中等待时间）。当线程利用率高或排队延迟显著增大时，说明系统接近过载，ConcurrencyLimiter 降低并发上限，减少新请求进入；当负载回落时再增大上限。算法上可用"负载系数 = 利用率 ×（1 + 排队延迟/服务时间）"估算有效负载，据此调节允许并发数（如按比例 K）。过载时的重要策略是"快速失败"：对超过上限的请求立即返回错误（拒绝/降级），而不是让它们排队等待——因为过载时排队只会延长延迟、放大积压，最终拖垮系统；快速失败让调用方及时感知并降级（如返回缓存、重试到其它实例），保护系统整体。这与"有界队列 + 拒绝"一致，避免无限堆积。

自适应限流是"动态反馈控制"：用利用率/排队延迟作观测，调节并发上限作控制。关键点是"过载时快速失败而非排队"——排队在过载时是负优化，快速失败把压力传导给调用方并触发降级。理解"负载估计 + 动态上限 + fail fast"三要素。