# 全局限流（Global Rate Limiting）最佳实践研究报告

> **版本**：v4.1（2026-10-30）  
> **文档属性**：技术研究与架构决策参考；非产品设计说明书、业务规则手册或生产验收报告  
> **适用对象**：银行业架构治理、应用研发、云平台、SRE、容量管理、安全合规及相关业务责任团队  
> **研究依据**：公开的一手工程资料、官方协议与金融行业标准，以及企业内部全局限流架构治理研究（来源见文末）  
> **适用性声明**：本文区分公开实践、研究归纳与项目级工程假设，属于架构研究输入，**不构成任何具体银行系统的运行压测、故障注入或真实容量验收证据**。任何阈值、保证等级、故障退化策略和成本收益结论，均须在对应系统中取得证据后才能采用。

---

## 执行摘要

**全局限流首先是共享容量与业务风险的治理问题，其次是分布式协调问题，最后才是算法实现问题。** 多实例、多集群、高并发均不是必须建设全局限流的充分理由。应依次回答三个问题：**是否确有过载风险需要控制；是否需要跨执行点协调；是否值得把若干场景的平台能力统一化。**

公开实践显示，Stripe 通过请求速率、在途并发和分级卸载组合防护；Google SRE 强调按调用方配额、客户端节流与过载保护；Netflix 以延迟反馈调整并发；Envoy 提供本地加全局限流以及按配额分发的扩展机制；GitHub 的案例揭示计数存储、复制和过期窗口的工程陷阱。这些案例共同支持的是**按风险选择多层控制、让执行点靠近保护对象、显式处理失效、逐步灰度**，而不是所有业务采用同一个全局组件。[1][2][4][5][6][8]

本文提炼的**推荐最佳范式**为：

1. **必要性先行**：只有共享瓶颈真实存在、局部方案不足、风险显著且全局协调产生可验证的增量收益时，才进入资源级全局限流建设。
2. **最小协调域**：全局范围由真实共享的资源与容量预算定义，可是一个外部通道、一个资源池、一个业务单元，不默认跨企业内部所有集群或数据中心。
3. **本地保护为底座**：本地速率/并发、背压、隔离和熔断是常规配置；全局协调仅针对局部看不见的共享总量。远程状态面不能无条件成为每个请求的硬依赖。
4. **策略与执行分离**：统一容量口径、规则契约、审计和符合性要求；执行端优先选网关、代理或中间件扩展，仅在内部业务语义确有必要时使用轻量 SDK；不强推全公司统一 SDK。
5. **明确保证边界**：原子扣减不等于跨故障硬上限；正常时的速率、瞬时突发、任意滚动窗口及日/月累计配额须分别定义精度和失效语义。不能证明上界的规则，不应宣称“有界超发”。
6. **增量建设、实证晋级**：先复用既有限流中心与执行能力，以单一、非硬上限的共享资源场景做对照试验；多个场景证实复用收益后，再考虑统一配额协调与平台化。

**结论**：全局限流不是普适基础设施必选项，而是为少数跨执行点共享约束而付出协调成本的专项能力。技术价值应以**下游受保护程度、关键业务可用性、误拒损失和新增故障风险**衡量，而不是 SDK 接入率、规则数量或“全局精度”单一指标。

## 一、研究对象、证据与术语

### 1.1 研究边界

本文研究的是对**请求速率、在途并发、累计用量及负载**进行约束的通用机制，以及配额协调、故障处理、统一治理和验收方式。不具体制定交易优先级、客户权益、业务准入、赔付补偿或账务处理规则；这些属于业务及相关风险责任主体。热点账户的账务模型改造、网络层 DDoS 清洗与数据库专项调优不在本文实施范围内，但会作为替代治理手段予以比较。

技术细节止于**可选方案、适用条件、状态与契约、关键依赖、一致性和故障边界**，不提供代码、伪代码、组件部署命令或臆造的生产阈值。本文对“应当”“必须”的使用，原则上指**本报告推荐的架构评审门槛**，不自动等同法定监管义务。

### 1.2 四种容易混淆的能力

| 类型 | 状态在哪里 | 可以解决什么 | 不能声称什么 |
|---|---|---|---|
| 独立本地限流 | 每实例各自计数 | 单节点防突发、线程池/连接池自保 | 实例规模变化时总量固定 |
| 集中治理的本地限流 | 中心发布规则，实例独立计数 | 统一配置、监控与审计 | 已具备跨实例共享配额 |
| 单机均摊/准全局 | 中心按实例数下发份额，实例独立消费 | 低成本粗略控制总体容量 | 能消除负载倾斜、扩缩容竞态导致的误差 |
| 真正的全局协调 | 跨执行点共享原子状态，或受约束地分配互斥额度 | 协调同一容量边界内的总消耗 | 无条件等同于跨故障严格硬上限 |

判断是否全局，关键不是“有没有中心页面”，而是**在定义的协调域内，额度是否可跨执行点被一致约束**。中心统一规则与全局协调是正交维度。

### 1.3 计量对象必须分清

- **速率**：单位时间内被接纳的请求或加权消耗，例如 TPS/QPS。应交代计量时点、窗口类型与允许突发。
- **并发**：同时占用某资源的操作数量；当延迟上升、队列积压时，通常比固定 QPS 更接近瓶颈。
- **累计配额**：日/月等周期内的操作量；不能用“每秒速率受控”推断累计不会超额。
- **资源健康/负载**：RT、错误率、排队长度、连接池与 CPU 等，属于过载判定与弹性卸载的反馈信号，不自动等于全局配额。
- **资源键**：由可信身份、资源和维度构成的限流实体；**热点键**是短时消耗异常集中于一个值的情况，接口总体 QPS 正常亦可能发生。

### 1.4 证据分层

本文区分三类内容：**A. 公开案例及官方文档所描述的事实**（第二章及参考资料）；**B. 从多个案例推导的可复用范式**（第三至第七章）；**C. 面向银行的推荐评审门槛**（第八至第十章）。B/C 是研究判断，不是被引用厂商共同发布的规范。对可用性、效率或精度的量化结论，均不得跨工作负载直接套用。

## 二、业界实践与可迁移结论

### 2.1 商业实践：每个案例解决一种典型问题

| 案例 | 公开的一手实践 | 可迁移结论 | 不宜外推的部分 |
|---|---|---|---|
| **Stripe** | 请求速率、并发请求、集群用量及 worker 负载卸载并用；按重要性保留容量；先观察再启用[1] | 区分调用方公平与系统过载；速率加并发；规则可灰度、可关停 | 公开案例中的分级、阈值不是银行通用值 |
| **Google SRE** | 后端按客户配额、分级卸载；调用端依据拒绝反馈自适应节流，减少无效网络请求[2][3] | 客户端退避与重试预算是限流的组成部分；拒绝自身也会消耗资源 | 内部服务可接受的请求损失及配额超卖不直接适用于资金交易 |
| **Netflix** | 以 RTT/排队趋势估算并发上限，采用 Vegas/Gradient2/AIMD 等控制思想[6] | 动态服务容量不宜只靠固定 TPS；并发与负载反馈可相互补充 | 自适应并发是局部过载控制，不等于跨实例总量配额 |
| **Cloudflare** | 采用近似/概率计数和更低内存开销的频次估算，针对高基数流量作取舍[7] | 热点发现与精确扣额可以分离；状态规模需要单独设计 | 概率估算可能高估，不能不经评估承诺零误拒 |
| **GitHub** | 从混用缓存迁至专门的分片 Redis 限流状态；遭遇窗口到期、主从视图与响应头不一致问题[8] | 防止计数被缓存淘汰；原子状态变化及一致的窗口语义比“用了 Redis”更重要 | 其存储拓扑与具体实现非所有环境最佳选择 |
| **Google/YouTube Doorman** | 协作式分布式配额分发、租约与安全容量；项目仓库已归档[9] | 租约可减轻每请求集中判定负载，但要管理额度闲置、重分配与服务故障 | 不能据此认为租约服务已有可直接使用且持续维护的通用产品 |

这里的“共性”是**多种控制手段组合、按需共享状态、按风险退化、先观测验证**。并不是速率、并发、全局配额、客户端 SDK 四种能力在每个系统都必须同时部署。

### 2.2 开源生态及其能力边界

| 技术/方案 | 可复用能力 | 选型关注 |
|---|---|---|
| **Envoy / Envoy Gateway** | 本地令牌桶与外部 Rate Limit Service（RLS）按 descriptor 做跨代理共享限流；两者可以组合[4][5] | 判定会产生额外依赖；请求是否被全部覆盖，取决于代理拓扑和配置 |
| **Envoy quota-based rate limiting** | Envoy 官方已提供按配额周期性上报与分配的扩展机制[4] | **官方文档说明该扩展尚无开箱即用的开源配额服务端参考实现**；已有扩展机制不等于具备完整可直接部署的配额服务端，需自主实现或集成兼容服务[4] |
| **envoyproxy/ratelimit** | 基于 domain/descriptor 匹配规则，支持全局及规则级 shadow mode[12] | 影子模式需核实计数与生产规则相互影响的实际语义，不能假定自动隔离 |
| **Alibaba Sentinel** | 应用级及集群流控、热点参数等功能[11] | 集群 token 服务的拓扑、降级和高可用要专项验证；单机均摊并不是真正共享总量 |
| **Redis/Valkey 及原子计数实现** | 以原子操作/脚本承载窗口计数、令牌状态 | 原子操作只解决正常期竞争；复制、故障切换、淘汰、热点键和跨分片事务仍要设计[8][10] |
| **Bucket4j / Redisson / Spring Cloud Gateway / APISIX** | 不同语言、存储与网关生态的复用路径[13][14][15] | 优先核实当前部署版本、特性及维护状态，不能把产品特性直接当作系统级保证 |

**选型结论**：不存在唯一“事实标准组件”。在已有网关时先评估网关内置全局限流；在多语言服务之间可评估代理；在内部方法与消息消费处可评估应用框架或中间件扩展；仅在性能、延迟或资源语义要求迫切时建设专用共享状态/配额协调能力。不得以“组件支持 cluster mode”替代故障一致性验证。

### 2.3 金融行业标准的准确边界

JR/T 0185—2020《商业银行应用程序接口安全管理规范》在全国标准信息公共服务平台标注为**现行、推荐性金融行业标准**，发布实施日期为 2020-02-13[16]。标准适用范围是商业银行**对外互联的应用程序接口**，其他类型接口可参照执行。流量控制、熔断、异常调用监测及通知等要求应结合**实际适用条款和企业内部制度**落实；不能由该标准直接推导“全公司所有应用必须建设全局限流”或“必须使用某 SDK”。

对于对外接口，规则约束的应用方、通知渠道和拒绝语义属于契约与合规协同事项；本文仅界定技术机制应预留相应能力，不代替业务协议或合规意见。

## 三、是否需要全局限流：先做建设决策

### 3.1 必须依次作出的三个判断

**第一问：是否需要控制流量？** 证据可能是资源瓶颈、突发冲击、租户互相挤占或外部协议额度。若仅存在容量不足且扩容、缓存、优化 SQL、分片治理或异步化更有效，应优先处理容量根因。若只涉及当前实例的线程/连接占用，局部并发与背压即可。

**第二问：是否必须跨执行点协调？** 证明多个执行点消耗**同一有限且难以独立保护**的资源。否则局部保护、动态均摊或单元内闭环足够。全局的“全”以共享资源的消费边界为准，而不是全公司规模。

**第三问：是否需要统一平台？** 需要多个独立场景证明策略、审计、适配、配额编排可复用；单一场景可由专项协调组件满足。统一平台的价值与单一全局状态面的必要性不是一回事。

### 3.2 四项必要性门槛：缺证据则暂缓建设

| 门槛 | 要回答的可检验问题 | 最少证据 | 不满足时的结论 |
|---|---|---|---|
| **A 共享资源** | 是否多方竞争同一确定的容量边界？ | 完整调用/旁路拓扑、资源归属、峰值及降容时容量 | **不建设全局协调**，按局部资源保护 |
| **B 替代不足** | 最佳可行的局部限流、并发、隔离、背压、扩容为何不够？ | 同负载下的对照试验或历史故障证据 | 优先采用较简单的替代方案 |
| **C 风险显著** | 不协调会造成何种不可接受的业务连续性、协议或安全风险？ | 影响等级、关键 SLO、事故记录及风险接受主体 | 无显著增量价值则不引入新依赖 |
| **D 协调有效** | 全局配额是否能准确约束瓶颈、减少重要风险且代价可接受？ | 压测/仿真、误拒与超发、故障注入、成本测算 | 仅允许进一步研究，不直接投产 |

对关键交易状态不确定、协议硬上限不可验证、灾备旁路未覆盖等**不可接受风险，采用准入否决或整改门槛**；不应以综合评分抵消。容量、业务与运维责任主体必须分别签字确认边界。

### 3.3 同时评估六类新增代价

技术复杂度（精度、时钟与配额守恒）、性能（P99 延迟与额外网络往返）、可用性（网络分区和中心故障）、业务适配（拒绝/重试/幂等及交易阶段）、运营治理（配置失误与应急值守）、长期维护（版本适配、多语言及依赖生命周期）。效益比较的基线应是**最优可行替代方案**，不是“什么都不做”。

### 3.4 分级建设，不以平台化为默认终点

| 等级 | 目标形态 | 适用条件 | 建设结果 |
|---|---|---|---|
| **L0 容量治理** | 压测、扩容、优化、缓存、资源划分 | 无可靠证据表明限流优于容量治理 | 不新增限流协调系统 |
| **L1 局部保护** | 网关/实例/池的速率、并发、隔离、背压与熔断 | 约束可由单个资源域独立执行 | 保留既有单机能力，允许成为稳定终态 |
| **L2 资源级全局协调** | 单一共享资源的跨执行点额度、最小状态面 | A—D 均成立且收益经验证 | 只协调必要的资源/租户/通道范围 |
| **L3 治理平台化** | 统一策略、契约、审计、认证与多执行端复用 | 多个 L2 场景成熟并存在真实复用需求 | 集中治理但不强制所有流量经过一个实时中心 |

L0—L3 是**建设选择**而不是所有应用必须依次晋级的“技术成熟度等级”。L1 完全可能是某系统的最佳终态；L3 也不意味着所有系统启用 L2。

### 3.5 L2 全局限流立项准入决策卡

L2 立项须提供**可复核的数字和证据位置**，不得仅以“流量大”“存在风险”“需要统一治理”作肯定回答。下表为架构委员会的最低材料要求；申请人应在附录 B 的表单中记录实际值、验证环境和证据链接。

| 准入关口 | 最低定量证据 | 决策规则 |
|---|---|---|
| **A 共享资源与安全容量** | **物理资源实体名称**、容量约束类型、正常/降容安全水位（例如 TPS、连接数或并发）、测量负载与 P99、已有安全余量 | 不能指出同一资源与可信安全容量，则不立项 L2 |
| **B 入口分母及替代不足** | 生产/批量/MQ/旁路/灾备的**全部消费路径**及执行端数量区间、最大并存规模、流量倾斜分布；L1/均摊/隔离/扩容对照结果 | 未证明独立保护不足，则优先 L0/L1 |
| **C 不协调的业务风险** | 事故次数或演练影响、关键业务 SLO 与受损时长、外部协议约束、风险等级及承受主体 | 无重要增量风险则不新增协调依赖 |
| **D L2 的增量收益** | 与最佳可行替代方案的初步定量对照或可复核仿真，列出下游过载时长、关键成功吞吐、误拒率、超额边界、P99 额外时延、建设运维成本及 PoC 目标 | 缺合理增量收益假设则暂缓 PoC；未完成受控实测不得生产上线 |
| **E 协调中心完全失联** | 故障演练至少覆盖连续 **5 分钟**和该规则最长租约/兜底周期（以较长者为准）；逐规则明确 fail-open、受限本地份额或 fail-close 的业务影响 | 业务/风险、资源与运行责任方必须共同确认；硬上限不得未经批准放行 |
| **F 执行与恢复保证** | 保证等级 G1/G2/G3、对端计量点、旧主隔离、扩缩容/切主/网络分区、旁路覆盖、回滚耗时及验收证据 | 不可接受风险未关闭，不得投产或对外承诺严格上限 |

**分母与均摊注意事项**：执行端数量不是把网关 Pod、服务实例和消费者相加；应按**同一资源实际消费单元**去重，考虑异构权重、弹性上限与滚动发布并存。用“总容量 ÷ N”算本地限额只是一种候选近似，其均摊闲置和流量倾斜误拒必须以观测数据证明；倾斜比 3:1 或均摊值小于 1 仅是提示性例子，不是统一准入阈值。**A—C 须以客观证据成立、D 须有可量化的增量收益假设，才可批准受控 PoC；D 的真实收益及 E—F 安全条件均取得验收证据，方可批准生产上线**。不能把安全否决项折算成综合分数。

## 四、从共性实践提炼的推荐最佳范式

### 4.1 范式一：以资源为中心定义最小协调域

先标识**受保护资源—共享调用方—流量入口—容量证据—执行位置**，再决定规则范围。一个真正独立的数据库分片，不因部署在多地域就必须共享全公司 TPS；不同地域共用一条外部清算通道，则可能需要以该通道为协调域。统一预算应可拆分到地域、单元、租户和执行端，并明确预算所有者。

推荐的资源层次是“**资源容量预算 → 业务/租户保障份额 → 执行端可消费份额**”。关键约束：同一预算不得被多处分配两次；保底总量不得超过可用容量；借用池可回收；未使用额度、在途租约及故障保留额度分别核算。跨地域若互不共享真实瓶颈，则优先各地域闭环；发生灾备流量接管时须同步迁移或重新授权预算，防止新旧单元叠加。

### 4.2 范式二：先分层保护，再按需增加协调

| 层 | 主要解决的问题 | 默认建议 | 何时需要共享总量 |
|---|---|---|---|
| **调用端** | 重试与请求浪涌 | 退避、抖动、重试预算、主动节流 | 通常不需要；不得把外部调用者的自律当成最终强制执行点 |
| **接入层** | 租户公平、接口额度、入口突发 | 网关本地过滤 + 可选全局配额 | 多网关竞争同一入口预算或外部承诺额度 |
| **服务层** | 服务自保、优先级与依赖劣化 | 局部并发、熔断、分级卸载 | 多服务/实例竞争同一非独立资源时 |
| **资源/出口层** | 热点键、连接池、第三方额度 | 资源附近的并发、排队和出口整形 | 共享单键、单通道或同一资源池时 |

**不能机械规定“L1 QPS 小于 L2 QPS 小于连接池容量”**：速率、并发和连接池数不是同一物理量；应按各级请求成本、扇出、服务时延与容量映射校验。对一个慢下游，只有入口 TPS 限制而无在途并发保护，仍可能耗尽资源。

**拒绝本身也必须低成本**：正常的 HTTP 429 拒绝应优先保持现有 HTTP 连接复用，而不是主动断开并诱发 TCP/TLS 建连风暴；极端过载或异常连接仍允许按连接层保护策略关闭。接入层应同时限定连接建立速率、并发连接与空闲连接占用，避免应用层限流把压力转移到握手和网络栈。[19] 调用端需要抖动退避、全链路重试预算和负载恢复期的渐进放量，不能把拒绝完全交给下游承担。[3]

### 4.3 范式三：治理与执行分离，控制面不进入常规热路径

推荐职责拆分为：**治理控制面**（规则与容量基线、版本、审批、应急、审计）、**执行数据面**（身份与资源键、局部保护、远程判定或租约消费、拒绝/排队）、**共享状态/配额协调面**（按需存储原子计数或分配互斥预算）、**观测面**（负载、拒绝、误伤、降级、审计）。

控制面失效时，执行端应能依赖经过验证的**最近有效规则和本地保护**运行；新规则下发失败、状态服务失联和观测系统故障，应是不同故障域与不同处置策略。若规则本身是不可突破的外部硬约束，则不得因控制面异常自动放行。集中治理可以沿用既有平台，不应为了“全局”新建第二套同类入口。

### 4.4 范式四：按保护目标组合速率、并发、负载与优先级

- **公平/额度**：按可信租户、渠道或资源键约束速率与累计配额；如需保证关键调用的份额，采用保底、可借用共享池和可回收配额。
- **实际负载**：资源压力的第一信号可能是 P99、排队和在途量，而非 TPS。对于耗时变化快的服务，局部或资源侧自适应并发通常比“全局固定 TPS 一把尺子”更贴合风险。[6]
- **热点资源**：单个账户/商户/产品码可以在接口总量未超时成为瓶颈；需要先定位热点的真实限制对象，再设置该键的访问速率或共享并发上限。限流只能减压，不能替代底层数据模型治理。
- **业务重要性**：技术平台承载优先级和预留配额，不自行决定谁应牺牲；业务与风险责任方提供分级依据，资源方提供容量依据。所有外部声明的优先级必须重新绑定可信身份。

### 4.5 范式五：保证强度按规则声明，不按组件名称声明

任何规则至少声明四组事实：**约束对象与计量点；正常期窗口/突发/并发语义；故障期行为；可证实的精度或超额边界**。同一个 Redis 原子脚本可以用于普通软配额，也可以作为严格方案的组成部分，但本身不能保证故障切换后的硬上限。[10]

## 五、核心技术选项与设计取舍

### 5.1 先选执行位置，再选算法和存储

| 执行方式 | 优先使用的场景 | 主要优势 | 必须接受的局限 |
|---|---|---|---|
| **API 网关/统一出口** | 南北向 API、渠道、共享第三方接口 | 统一执行、改造少、覆盖与审计集中 | 看不到全部内部业务语义；需核查旁路 |
| **服务代理/Sidecar** | 多语言 RPC、服务间访问 | 可复用流量层特性，降低语言耦合 | 不天然覆盖方法级处理、MQ 消费和非网络操作 |
| **中间件/框架插件** | MQ、批量、任务调度 | 靠近消费和并发来源、易做背压 | 受扩展机制及版本兼容约束 |
| **应用 SDK/业务 API** | 只有业务上下文可见的内部方法或复杂操作 | 可识别深层资源键、成本和阶段 | 语言/版本治理重，容易把协调故障注入业务路径 |

**SDK 不是全局限流的先决条件。** 只有网关/代理/中间件无法覆盖执行点，且业务上下文确属必要，才建议采用轻量 SDK。SDK 负责规则标识、可信维度传递、判定、超时、降级和观测；**交易状态回滚、资金补偿和具体业务拒绝处置仍由业务系统负责**。

### 5.2 四类跨实例协调模型

| 模型 | 主要原理 | 性能与精度 | 主要风险 | 推荐位置 |
|---|---|---|---|---|
| **A 无共享状态/动态均摊** | 各实例执行独立阈值，可按副本数刷新份额 | 无远程判定；总量随实例与倾斜波动 | 误拒、扩缩容期超发、实例粘滞 | 非硬上限、稳定拓扑的低风险场景 |
| **B 集中判定服务** | 每请求到统一判定端取决策 | 相对易形成统一计数口径；每请求增加 RTT | 中心负载、可用性与故障放大 | 规模有限、服务边界明确的场景 |
| **C 分片共享计数** | 按资源键路由，存储侧原子改变状态 | 多租户/多键可扩展；每请求访问共享存储 | 复制丢失、热点分片、跨键原子性 | API 租户配额、资源键限流的优先候选 |
| **D 全局分配 + 本地租约** | 周期性分配受约束的份额，本地消费 | 请求热路径少网络往返；可能闲置与再分配滞后 | 租约重叠、额度回收、故障期预算叠加 | 高吞吐、低延迟且能容忍或证明误差的场景 |

不能仅按“多少万 QPS”设固定选型门槛；关键是**共享状态的每秒判定次数、命中规则数量、P99 预算、活跃键基数与可接受一致性代价**。D 的协调流量通常随执行端数量和刷新频率变化，而不是随请求数线性变化，但若其保证条件要求每笔远程确认，就会失去该优势。[4][9]

### 5.3 算法与控制量：使用条件而非排名

| 算法/机制 | 适合 | 不适合或需补强之处 |
|---|---|---|
| **令牌桶** | 平均速率与可控突发、成本加权 | 突发可能在多个执行端叠加；不能单凭平均速率证明任意滚动窗口硬限额 |
| **漏桶/出口整形** | 平滑外发、减少瞬时冲击 | 需要有界队列与等待时限；请求进入网络后的到达顺序还受传输影响 |
| **固定窗口计数** | 日/月调用额度、可接受边界抖动的计数 | 窗口交界短时突发；应明确时区与计费归属 |
| **滑动窗口计数器（近似）** | 高吞吐、成本敏感的频控 | 用相邻窗口加权估算会有误差，不能承诺精确无超额 |
| **滑动日志/精确滚动窗口** | 短窗严格约束且可承担高状态成本 | 每键内存、清理、原子操作与故障持久性成本更高 |
| **并发许可/信号量** | 线程、连接、热点对象与外部调用在途保护 | 远程申请及释放可能丢失；需处理超时、代际和许可泄漏 |
| **自适应并发** | 延迟/排队恶化、容量动态变化 | 对低样本、高方差和误反馈敏感；不是累计配额的替代品 |
| **Sketch/近似频次识别** | 海量维度下筛选候选热点 | 可能误判；高价值拒绝优先经精确计数复核，或证明误拒概率可接受[7] |

**选型顺序**：先明确资源和保护目标，再确定是速率、并发、累计还是负载；其次确定时间窗口、突发和精度；最后选原子状态、租约以及算法。很多系统的优选是“局部并发 + 网关频控”，不是“全局滑动窗口”。

**时间源和窗口边界规范**：

- **共享计数窗口**：应由协调域内的权威计数方统一决定窗口及事件计量时点，不得以分散应用节点各自的墙上时钟直接比较精确窗口。使用 Redis `TIME` 等服务端时间可避免客户端时钟各异，但**服务端时间是墙上时间，不是单调时钟**；切主时间不连续、NTP 前跳/回拨、跨分片时间差与存储 TTL 的实际过期行为仍须评估。[20]
- **本地租约有效期**：以执行端单调时钟（Monotonic Clock）度量本地经过时间，不把不同主机的单调时钟读数直接比较。租约授予/接收的传输延迟、时钟误差安全裕量、续租失败、代际切换及旧额度不可复用，都必须有独立的规则。
- **业务日/月配额**：统一时区与业务日历，明确日切、跨日请求和计量归属；不能用本地 TTL 自然到期代替合同约定的累计配额口径。
- **时钟异常处置**：检测跳变/不同步时停止不可信的新额度分配、告警并执行该规则已批准的保护策略；对 G1/G2 需通过前跳、回拨与主备切换故障注入证明保证边界，**NTP 同步本身不是一致性证明**。

**同步排队与剩余超时预算**：限流器排队、获取许可、下游执行和返回响应，都会消耗由上游传入的请求截止时间（Deadline）推算出的剩余超时预算。同步 HTTP/RPC 请求必须采用有界队列并计算可观测的剩余预算，等待上限受**可信的剩余超时预算**约束，同时为下游 P99、网络和收尾保留安全余量；预算不足则快速失败，不得排队到上游已超时后再执行下游副作用。若上游未传递 Deadline，应使用接口已批准的总超时预算；还要验证取消传播、许可释放和排队超时后的未知态处理。可异步消费的 MQ/任务有不同的排队与积压语义，不应机械套用同步 RPC 规则。

### 5.4 资源键、状态与规则的最小契约

每条规则建议包含以下设计属性，作为跨产品的**语义契约**，不要求各产品使用统一字段名：

| 类别 | 最小内容 | 约束 |
|---|---|---|
| 规则身份 | 规则 ID、版本、所有者、有效期及变更审批 | 策略变更可回滚和审计 |
| 保护对象 | 真实资源、协调域、所有相关入口 | 不遗漏绕行、消费与灾备入口 |
| 维度 | 可信主体、资源键生成规则、缺失字段策略 | 先认证与授权；敏感值采用带密钥摘要，防止枚举 |
| 计量 | 控制量、单位、窗口、计量时点、权重、突发、权威时间源与日切边界 | “请求到达”与“下游已执行”不可混用；窗口与时间跳变语义需明确 |
| 额度 | 总预算、保底/借用、单元份额、允许并发 | 预算守恒及回收规则明确 |
| 判定 | 放行/拒绝/排队、来源、剩余额度（如可得）、原因、Deadline/取消语义 | 排队容量与等待上限有界且服从剩余超时预算 |
| 可靠性 | 保证等级、超时、分区、切主、租约失效处置 | 正常、超时、切主、分区四态有记录 |
| 审计 | 决策追踪 ID、规则版本、受控主体、状态及时间 | 拒绝事件可定位；不在指标标签暴露高基数敏感键 |

**幂等边界必须独立**：业务幂等键用于防止重复产生业务副作用；限流决策 ID/预留记录用于避免重试重复消耗配额。两者不能仅凭名称相同就视为同一事务保证。若远程判定超时、业务是否执行不明，应进入“结果未知”的受控核查流程；不能因为超时就自动重放已经可能发生副作用的操作。

**额度消费与回补必须符合计量语义**：已发生计量的请求尝试（Attempt）即使业务失败，通常也不退还速率令牌；**并发许可必须在对应资源占用结束后释放**，无论业务成功、失败还是取消，异常恢复应防重复释放/许可泄漏；日/月累计额度如按尝试计量，原则上不因业务失败回补，如合同按成功笔数计量，则依据可审计的状态与对账结果调整。尚未发生计量事件的合法预留可以按预留协议撤销，但不能把业务失败回滚等同于撤销已消耗的物理资源额度。对未知态交易禁止自动按业务失败处理并回补。

多个规则同时命中时需明确规则优先级、是否联合原子扣减、额度预留与确认/撤销的条件。跨分片没有天然单事务，串行扣减会造成部分额度浪费；若涉及合同额度或共享许可，需要在架构设计阶段选择预算预留、单分片共同判定或接受可测误差，而不是由上层应用随意重试。

### 5.5 高可用、故障切换与保证等级

为避免把“正常期原子计数”误认为“跨故障严格上限”，按实际保证边界定义以下等级：

| 等级 | 本文定义 | 必需证据 | 不能误称 |
|---|---|---|---|
| **G1 严格上限（限定观测点）** | 在**明确定义的执行点、窗口/总量及故障模型**内，不超出额度 | 独占且无旁路的强制执行点、故障期保护性拒绝、不能重复消费的持久预算/代际隔离、实测覆盖切主与传输抖动 | 单纯 Redis 原子扣减、故障时 fail-close 就自动满足 G1 |
| **G2 经证明的有界偏差** | 给定故障模型中，超额/误拒在**可计算且经测试校核的上界**内 | 租约互斥、扩缩容上限、主备丢写上界、故障预算、突发与滚动窗口测量 | 只有“正常期精确”、却没有故障上界仍称 G2 |
| **G3 尽力而为** | 只承诺统计或趋势控制，不承诺全局总量及故障上界 | 清楚标注适用场景与失效语义 | 对外宣称硬约束、零超额 |

G1 不是“所有异常情况下绝不可能超额”的无限声明；它是**对指定执行边界和验证过的失效假设**作出的可审计保证。尤其是外部协议按对端**任意滚动 1 秒到达量**计算时，银行应用层的“发送调用先后顺序”不一定等于对端的实际到达顺序；若观测点不一致、存在网络缓冲或多出口旁路，不能声称 G1。需先由对端、网络和出口方共同确定计量点与可强制限制的位置，再验证故障切主时旧主不可继续发出（fencing/独占通道）。未做到的只能下调承诺级别或不启用该硬限制场景。

对 G2 特别注意**混合故障态**：一部分执行端继续使用有效租约，另一部分进入本地兜底，**两类额度会叠加**。仅以“实例数乘以每实例兜底值”估上界是不充分的。可选控制包括：把故障额度从正常可分配池中**预先、互斥地划出**，限定最大执行端数，确保过期租约不会和新租约双重使用，记录配额重分配代际。即使长期平均预算守恒，**瞬时突发和任意滚动窗口峰值仍需单独证明**。

日/月累计额更特殊：故障次数可累积，不能把“每次最多 5 分钟”误作“全天只故障 5 分钟”。如要承诺降级期日累计上界，须采用**跨实例、跨重启有效且不可重复领取的独立预分配预算**，或故障域独立的原子预算账本；若二者均不可行，应在累计额规则上拒绝、暂停，或明确降为 G3。无状态弹性实例无法可靠认领稳定实例预算时，不得使用依赖该身份的预分配方案。

存储复制亦非免费一致性：Redis 官方说明默认异步复制；即使使用 `WAIT`，也不会把该系统变为强一致的 CP 系统，切主仍可能丢失已确认的写入[10]。因此 G2 的上界需要考虑**主备丢写量、租约叠加、容错放行、重试重复扣额、短窗突发**，而非只检查原子操作是否正确。

### 5.6 失效策略不应全公司一刀切

| 情形 | 原则性策略 | 必须记录/验证的边界 |
|---|---|---|
| 一般查询、软容量保护 | 受约束的局部保底或有限放行，可结合降级 | 全局不可用不应造成更大损害；本地保护有效且有容量余量 |
| 共享脆弱资源/热点单键 | 优先资源侧保护、拒绝或极小额保底 | 本地均摊不能放大共享并发；连接/许可释放与故障回收明确 |
| 外部协议强总量/严格累计额度 | 无可靠额度时保护性拒绝或停发 | 不得通过“一键关停”绕过协议约束；确定计量执行点 |
| 多活切换与网络分区 | 单元配额互斥、流量与预算同步接管 | 切主旧实例隔离、迁移前后预算不叠加 |
| 错误规则发布 | 版本校验、影子、渐进生效、紧急回退 | 核心硬约束回退到已审定安全配置，而不是裸放行 |

“fail-open 保可用”只适用于**放行风险低于拒绝风险**、且能由局部保护承担后果的规则；“fail-close 保安全”也不能自动证明不会误拒关键业务。规则必须定义受保护资源、损失方向、告警级别、持续时间、恢复门槛与人工责任人。

### 5.7 高基数、热点与存储隔离

优先建立**维度白名单、活跃键数量上限、保留期、热点分片容量和异常键回退策略**。极高基数资源先用低成本摘要/估算识别候选，再按业务误伤容忍度进行精确确认。对共享状态存储，按命中热点、负载和故障域划分分片；若可隔离，限流状态应避免与会被任意淘汰的通用业务缓存混用。必须监测内存驱逐、主从滞后、时钟异常、窗口异常和拒绝指标的语义一致性。[7][8]

## 六、重点场景的推荐范式（只定义技术边界）

| 场景 | 优先替代/基础措施 | 若确需全局协调，推荐控制 | 特殊约束 |
|---|---|---|---|
| **多渠道共享核心交易能力** | 服务隔离、并发、关键资源容量基线 | 以实际共享核心资源为域；关键业务保底 + 可借用余量 | 优先级、拒绝和可恢复语义由业务侧确定；平台不自行定规则 |
| **开放 API 多租户配额** | 网关本地限流、认证与接口准入 | 网关侧共享租户/接口速率和独立累计账本 | 对外调用方不持有可信强制租约；通知与契约遵循适用制度[16] |
| **共用第三方/清算通道严格额度** | 出口整形、并发池、渠道隔离 | 在可信、无旁路的统一出口实施通道预算 | 若要求 G1，需验证对端计量点、滚动窗口、切主隔离；否则不能对外承诺 |
| **热点账户/商户/产品码** | 热点 SQL、锁竞争、资源模型专项治理 | 资源键级并发/速率，尽可能靠近资源执行 | 只保护真实热点资源，不把接口总量作为唯一阈值；长期热点需专项治理 |
| **营销活动突发** | 缓存、入口排队、异步、业务容量预热 | 经证实的共享瓶颈可采用短期资源预算 | 避免把营销流量与关键交易放在无保障的先到先得桶里 |
| **MQ 消费、批任务、日切** | 消费背压、并发、触发打散、队列容量 | 当多消费组竞争同一外部有限资源时协调预算；结合业务时段与联机负载动态让路 | 队列上限、积压、批联配额迁移、未归还租约及恢复速率均须受控；不天然需要全局层 |
| **多活/单元化接管** | 单元自治、资源本地保护 | 仅对确实共享的外部/跨单元容量设协调预算 | 接管流量与额度同时迁移；先核实资源是否真正跨中心共享 |
| **重试风暴/依赖劣化** | 退避、抖动、重试预算、熔断、自适应并发 | 通常先不设全局固定 TPS | 防止拒绝与恢复后的重试叠加使故障扩大[2][3] |
| **复杂成本不等接口** | 查询优化、资源隔离、分级执行 | 有可靠成本测度时再使用加权配额 | 权重必须源于实测资源消耗而非业务主观估计 |

**批联动态分时预算的推荐范式**：银行资源负载具有日间联机、夜间日切、月末/季末核算和临时补跑等潮汐特征。共用核心资源时，以**联机保障份额 + 批量可让路份额 + 有界共享池**为基础，结合经过审批的时段日历（Time-of-day Quota Shifting）和实时联机 P99、队列、连接池、负载等信号调整批量执行速率。进入联机高峰或资源降容时，优先暂停批量新增消费、收缩可借份额并执行有序让路；恢复时分批扩量，避免批量积压集中释放。**时段切换不意味着已发租约立即消失**：必须规定旧租约清退/自然到期、代际隔离、在途请求收尾、批任务重入与预算不可双重消费；日切跨日归属需独立按业务日历确定。若不存在共享瓶颈，优先调度错峰和局部背压而非建设全局配额。

**银行场景的边界**：技术层要预留优先级、配额、状态和拒绝语义的可配置点，但不能凭限流报告决定交易的不可撤销性、资金状态归属、客户合同责任与补偿流程。对于拒绝可能发生在产生外部副作用之后的路径，必须由业务链路提供幂等、查询或对账机制，不能以“限流之前拒绝”作为未经验证的保证。

## 七、统一治理：统一什么，不统一什么

### 7.1 优先统一五件事

1. **语义与标准**：资源/窗口/控制量/保证等级/可信维度的公共词典及变更约束。
2. **容量与责任**：共享资源预算出处、业务分级责任、阈值校准和例外审批。
3. **接口与审计**：共享状态/决策服务协议、跨执行点追踪、观测口径及故障事件。
4. **符合性验证**：统一测试场景、上界核算、回退和版本兼容性要求。
5. **治理入口**：尽量复用既有统一规则平台，避免另建控制台造成同一规则多处维护。

**不宜强行统一**：算法、语言 SDK、所有应用的动态并发控制器、所有规则的 fail-open/close、跨地域实时计数服务。统一技术实现只有在成本、覆盖、维护和故障域均证明有优势时才成立。

### 7.2 平台化的正确边界

已有集中管理的本地限流中心，可以保留规则下发、告警和本地保护，在其中**增加经批准的共享资源规则类型与后端协调能力**；但“存量零改造、最坏情况不劣于现状”**不是自动成立的事实**。必须确认新规则不改变存量规则语义，且额外同步依赖、配置误配和失效回退不会扩大故障范围。对新接入规则，可要求强制符合性认证；对既有系统，宜按真实风险定向升级。

平台团队提供可复用的“铺好的路”：网关策略、代理扩展、适配组件、轻量 SDK 参考实现及测试套件。应用团队可以选择兼容实现；如果必要性论证表明 L1 足够，不应因全公司推广指标强制其接入 L2。

### 7.3 角色边界与规则生命周期

| 活动 | 业务/风险责任方 | 资源/应用责任方 | 平台/架构 | SRE/运维 | 安全合规 |
|---|---|---|---|---|---|
| 界定优先级、拒绝与合同约束 | 主责 | 参与 | 提供能力 | 参与 | 审核适用要求 |
| 容量基线和资源瓶颈 | 参与 | **主责** | 评审 | 压测与观测 | — |
| 协调范围与算法/形态 | 提供约束 | 联合设计 | **主责评审** | 审核运行成本 | 安全评估 |
| 规则发布/例外与故障切换 | 关键规则会签 | 实施确认 | 策略校验 | **执行与演练** | 高风险规则会审 |
| 事后校准与退场 | 评价业务影响 | 复盘容量 | 复盘复用价值 | 复盘故障证据 | 复核审计 |

每条规则必须有生命周期：提出需求、确认容量与业务边界、对照方案评审、影子校准、灰度发布、周期复核、容量变化触发重审、停用退场。**未经审定或长期无人维护的静态阈值本身可能成为系统性风险。**

## 八、可靠性与安全的不可省略项

### 8.1 典型故障必须有明确处置

| 风险 | 典型错误 | 必须验证的处理 |
|---|---|---|
| 配额/计数中心失联 | 全量停服或盲目放行 | 逐规则失效语义、极短超时、受控降级与立即告警 |
| 网络分区 | 两侧同时认为自己是授权主节点 | 主代际隔离、租约互斥及双边容量控制 |
| 复制切主与丢写 | 认为原子操作足以防止超额 | 计量丢失范围并纳入保证等级[10] |
| 租约重叠/扩容 | 新旧实例重复取得完整预算 | 最大实例数约束、额度不可重复领取、过期与回收规则 |
| 静态配置误配 | 大范围误拒或裸放行 | 参数合法性校验、双人审查、影子、灰度与回滚 |
| 无旁路假设失真 | 灾备/脚本/内部调用绕开限流 | 入口盘点、拓扑变更控制及灾备演练 |
| 高基数键/热点状态 | 内存耗尽或单分片过载 | 键基数限额、热点分散、降级观察与隔离 |
| 并发许可泄漏 | 永久拒绝或重复释放 | 有界许可生命周期、代际/幂等归还、异常回收 |
| 多规则与请求重试 | 重复扣减、配额损失或副作用重复 | 决策身份与业务幂等分离、结果未知状态和对账 |
| 影子与正式规则干扰 | 影子期污染真实预算 | 独立统计或受验证的只读模拟；启停对照试验 |
| 时钟跳变/窗口漂移 | 时间回拨重复计量、时间前跳提前过期、不同节点租约错序 | 权威时间源、时钟漂移监测、跨切主边界和跳变注入测试 |
| 同步排队透支 Deadline | 上游已超时，下游才被放行执行 | 全链路 Deadline 传播、有界等待、取消传播和余量不足快速失败 |
| 同步重试与连接风暴 | 大量 429 后同一时间重试，主动断连造成 TLS 握手尖峰 | 退避抖动、重试预算、连接复用和连接速率保护 |

### 8.2 观测指标围绕“保护价值”而不是拦截数量

**业务效果**：关键请求成功率/超时、重要业务 SLO、实际有效吞吐、受控拒绝与可能误拒。**容量效果**：下游瓶颈资源过载时长、排队、在途量、热点分布、保底兑现及共享池利用。**协调效果**：全局超额、突发与滚动窗口峰值、租约闲置/回收、状态面依赖调用和 P95/P99 决策时延。**运营与安全**：规则覆盖/偏差、版本分布、发布和回退时间、故障降级时长、旁路发现、策略错误与审计完整性。

拒绝明细需要可追踪到规则与请求，但**不得将原始账号、证件号、手机号或高基数资源键直接作为时序指标标签**。采用可控的审计明细与脱敏/密钥摘要，按企业内部数据安全和留存制度处理。对外 HTTP `429 Too Many Requests` 表示请求频率受限，可返回明确的规则语义和 `Retry-After`；系统不可用/过载可按语义考虑 `503 Service Unavailable`，但不能把这些状态码自动等同于“该笔资金交易可重试”。`Retry-After` 可采用 HTTP 日期或非负整数秒数，本身**不要求随机化**；服务端给出可解释的最早重试时间或恢复区间，客户端在尊重这一约束的前提下采用指数退避、随机抖动（Jitter）、总 Deadline 和重试预算以避免惊群。[17][18][3]

**重试预算的评审约束**：企业内部调用方应限定单次操作重试次数、总体重试流量比例、跨层重试倍增及恢复期放量；“重试请求不超过总请求 10%”仅可用作待验证的候选值，并非全公司统一标准。非幂等请求或状态未知的资金交易必须先查证/对账，不得按一般 429/503 自动重发。接入侧监控重试比例、同秒重试峰值、连接建立速率、TLS 握手成本和拒绝响应 P99；正常 429 尽量保持 HTTP 连接复用，极端过载和恶意连接则执行传输层保护，并验证真实客户端行为。[18][19]

### 8.3 规则开关必须区别“软保护”与“硬约束”

软保护规则可按审批进入影子、收紧、暂停或本地保底；真正受外部硬约束的规则，其应急操作只能**转入已审定的更保守模式、切换可信执行点或停发**，不能通过总开关消除强制约束。任何应急动作应留存操作者、原因、范围、自动失效/复核时间与恢复验证结果。

## 九、验证路径、验收标准与退出机制

### 9.1 按决策闭环推进

| 阶段 | 必须完成的研究/工程活动 | 形成的证据与决策 |
|---|---|---|
| **1 风险和容量画像** | 共享资源拓扑、峰谷与突发、降容容量、调用方与所有旁路清单；明确业务后果 | 共享资源容量画像；A/C 门槛判断 |
| **2 替代方案对照** | 在同样负载下比较 L0、L1、隔离/背压、扩容、均摊和 L2；测量误拒、下游保护与额外依赖 | 架构决策记录（ADR）；B/D 门槛判断 |
| **3 受控 PoC** | 选择单一非硬上限共享资源，先不拦截；分别测试每请求计数与必要时的租约 | 算法及形态对比、容量开销、故障假设验证 |
| **4 影子与灰度** | 规则影子态统计、参数校准、小范围拦截，保留对照组和回滚路径 | 误拒、收益、SLO、回滚演练记录 |
| **5 运行复核** | 定期重测容量；验证灾备、扩容、重试、变更与退场 | 持续运营证据；决定保留、缩小或退出 |
| **6 平台化再决策** | 多个独立 L2 场景证明共同协议和治理模型可复用 | 是否建设 L3 的专项 ADR，而非自动推进 |

**不建议把支付链路或协议硬上限直接作为首次 PoC。** 首个受控场景宜选共享瓶颈明确、允许软额度误差、故障可隔离且具有可对照指标的资源。本文未提供任何可直接作为生产阈值的假设容量参数。

### 9.2 最低验收集合（全部需要有实测记录）

| 验收维度 | 关键试验 | 判定依据 |
|---|---|---|
| 必要性 | 同负载比较 L1 与 L2；包括业务混合流量与降容 | 证明共享瓶颈确被保护、关键业务净收益大于代价 |
| 正常期正确性 | 单/多维度、加权、日累计、窗口边界、跨实例倾斜、分时预算切换 | 在规则声明的时间和计量口径内达标，旧/新预算不可叠加 |
| 服务性能 | P95/P99 额外时延、限流中心吞吐、资源成本、高基数压力 | 不超该业务明确分配的性能预算；无统一拍脑袋指标 |
| 保证边界 | 瞬时突发、任意滚动窗口、累计量分别校核 | G1/G2 的声明上界有完整证据，否则降级声明 |
| 故障 | 超时、网络分区、重启、主备切换、丢写、扩缩容、租约叠加、NTP 前跳/回拨 | 失效语义与预案一致；无未经批准的放量和错误过期 |
| 安全与完整性 | 可信租户、优先级伪造、资源键脱敏、旁路、状态未知重试、配额释放/回补 | 无身份绕过、许可泄漏、错误回补或业务副作用放大 |
| 传输与排队 | Deadline 传递、队列等待与取消、429 后客户端重试惊群、连接复用与握手开销 | 不出现等待透支、同步重试脉冲或异常建连风暴 |
| 策略运维 | 影子与正式隔离、错配回滚、灾备切换、开关权限 | 告警可用、回退有效且硬约束不被旁路 |
| 持续收益 | 一段完整业务周期的误拒与资源指标 | 与对照组比较，净收益稳定、维护成本可接受 |

每份实测记录至少包含：**规则及版本、协调域与保证等级、环境与压测数据、故障注入点、预期边界、实际峰值及偏差、恢复耗时、业务影响、执行人、时间与结论**。不能用“已设计覆盖”“代码通过单测”代替验收。

### 9.3 严格额度与跨故障保证的五项上线前置条件

对拟承诺严格出向额度、跨地域共享预算或累计故障预算的项目，必须逐项提供外部确认或运行验证结果：

- **计量点**：对端/合同计量的是请求发起、出口发送还是对端入口实际到达，滚动窗口如何定义？
- **旧主隔离**：在真实强制执行点能否隔离旧实例、旧连接或旧租约？仅控制应用内部互斥不够。
- **执行覆盖**：所有正式、应急、批量、灾备、运维出口是否被完整控制且可审计？
- **降级预算身份**：容器是否具有稳定、不可重复认领的持久身份？若没有，预分配降级日预算能否换用独立账本？
- **计数丢失与业务未知态**：异步复制切主、远程发送后故障如何对账？能否阻止不安全的自动重放？

**以上均为项目级前置约束，不因方案文档已经论证而视为完成。** 不满足条件时必须下调保证承诺、变更架构或不投产；计时/短窗、混合故障态、Deadline、重试放大和分时预算回收亦须按第 8、9.2 节纳入验收。

### 9.4 明确退场条件

若复盘发现不存在共享瓶颈、L1 或扩容在同等成本下更有效、全局策略长期误拒、状态面故障超出收益，或业务资源迁移后不再共享，应**减小协调域、停用 L2 或回退 L1**。每条规则应有退出条件与责任人；建设覆盖率不是保留系统的正当理由。

## 十、架构评审的关键反模式

| 应避免 | 原因 | 推荐替代 |
|---|---|---|
| “实例多，所以必须全局” | 忽略真实容量归属 | A—D 证据门槛及最小协调域 |
| “全公司统一装 SDK” | 侵入业务、版本升级慢、覆盖仍可能不完整 | 统一语义与认证，执行端按场景选择 |
| “先上 Redis/算法，再找场景” | 把实现方便误认为风险收益 | 先资源、容量、失效后选型 |
| “全局阈值 = 所有资源安全” | TPS 无法涵盖慢请求、热点与资源成本 | 配合并发、背压、隔离和资源健康信号 |
| “原子判定/Redis HA = 硬上限” | 主备丢写、分区、绕行仍可能超发 | G1/G2/G3 与计量点实证 |
| “限流中心不可用一律放行” | 脆弱下游或外部合同可能被打穿 | 按规则决定保护性拒绝或受控保底 |
| “租约 + 兜底自然不会超额” | 混合故障态额度可叠加 | 互斥分池、代际与复核三类上界 |
| “平均 QPS 受控即可满足 1 秒硬限” | 突发与滚动窗口独立于平均速率 | 真实执行点整形与窗口压测 |
| “单机均摊 = 全局” | 倾斜误拒与扩容误差依然存在 | 只在低风险、误差可接受时使用 |
| “拦截越多越有效” | 可能以牺牲正常交易换取漂亮指标 | 用下游保护、关键 SLO 与误拒评估 |
| “影子规则自动安全” | 计数与状态可能污染正式判定 | 明确隔离并做启停对照 |
| “写了预案就具备高可用” | 稀有故障路径常未被验证 | 定期注入、演练、更新责任与退场 |
| “不同机器的本地时间可直接校验严格窗口” | NTP 跳变、主备漂移和 TTL 语义导致错窗 | 统一计量时间、单调租约计时与跳变演练 |
| “同步等待令牌只会增加一点延迟” | 等待可能耗尽上游 Deadline，放行已失效的请求 | 有界排队、端到端剩余预算和快速失败 |
| “所有客户端收到相同 Retry-After 后照点重试” | 同一秒重试形成二次流量脉冲 | 客户端抖动、总重试预算与恢复分批放量 |
| “拒绝 429 就主动断开所有连接” | TCP/TLS 重建可能比拒绝判定更贵 | 正常拒绝优先复用连接，异常过载分层连接保护 |
| “日切按时修改预算，旧份额会自然消失” | 在途租约和未完成批任务可能冲击联机 | 生效代际、回收等待、批量动态让路与缓升 |
| “业务失败就退还全部限流配额” | 按请求尝试计量的速率令牌已被消耗，但并发许可仍必须释放 | 按速率、并发、累计计量语义分别处理 |

## 十一、结论与实施建议

**建议确立的架构原则**：坚持业务驱动、风险导向、最小必要、局部优先、证据决策、分层执行。将“是否需要限流”“是否需要跨执行点协调”“是否需要统一平台”作为三项不同的批准事项；在必要性证据不足时以 L0/L1 为稳定终态，不默认建设全局服务。

**对于确需 L2 的资源**，以共享容量与真实执行点为中心，按保底与借用机制配置预算，优先复用既有网关/代理/中间件；在准确性、性能及可用性间逐项取舍，逐条规则声明保证等级、故障模式和验收证据。严格额度不允许以无法验证的“高可用”设计或统一开关掩盖约束风险。

**对于统一平台**，先统一语义、策略、契约、审计、容量责任和符合性测试；对有成熟多个 L2 场景且重复建设显著的领域再引入 L3。平台化成功标准是更少系统性故障、更稳定关键业务、更可解释的容量治理与合理的长期投入，而非技术栈一致或接入率最大化。

---

## 参考资料与依据

> 优先保留官方技术博客、官方文档、标准信息平台和开源项目原仓库。以下访问入口截至本稿修订时可作为核对依据；**功能、接口和维护状态可能随版本变化，项目选型时须再次核实**。文内引用编号对应本表。

| 编号 | 一手出处 | 用途 |
|---|---|---|
| [1] | [Stripe Engineering — Scaling your API with rate limiters](https://stripe.com/blog/rate-limiters) | 速率、并发、卸载组合及影子上线 |
| [2] | [Google SRE Book — Handling Overload](https://sre.google/sre-book/handling-overload/) | 客户端节流、后端配额与过载保护 |
| [3] | [Google SRE Book — Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) | 退避、重试与级联故障 |
| [4] | [Envoy — Global rate limiting](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting) | 每请求 RLS、本地协同及 quota-based 扩展现状 |
| [5] | [Envoy Gateway — Rate Limiting](https://gateway.envoyproxy.io/docs/concepts/rate-limiting/) | 网关本地与全局分层执行 |
| [6] | [Netflix — concurrency-limits](https://github.com/Netflix/concurrency-limits) | 自适应并发与反馈控制 |
| [7] | [Cloudflare — How Pingora keeps count](https://blog.cloudflare.com/how-pingora-keeps-count/) | 高基数频次估算的收益与误判边界 |
| [8] | [GitHub Engineering — How we scaled the GitHub API with a sharded, replicated rate limiter in Redis](https://github.blog/engineering/how-we-scaled-github-api-sharded-replicated-rate-limiter-redis/) | 分片、缓存淘汰、TTL/复制一致性陷阱 |
| [9] | [Google/YouTube — Doorman](https://github.com/youtube/doorman) | 协作式租约配额范式；仓库归档 |
| [10] | [Redis — Replication](https://redis.io/docs/latest/operate/oss_and_stack/management/replication/) | 异步复制与 WAIT 的保证边界 |
| [11] | [Alibaba Sentinel — Cluster flow control（官方 Wiki）](https://github.com/alibaba/Sentinel/wiki/Sentinel-%E9%9B%86%E7%BE%A4%E9%99%90%E6%B5%81-%E5%85%A5%E9%97%A8%E6%8C%87%E5%8D%97) | 集群流控与接入范式 |
| [12] | [envoyproxy/ratelimit — README](https://github.com/envoyproxy/ratelimit/blob/main/README.md) | descriptor、shadow_mode 能力 |
| [13] | [Apache APISIX — limit-count](https://apisix.apache.org/docs/apisix/plugins/limit-count/) | 网关计数与策略选项 |
| [14] | [Spring Cloud Gateway — RequestRateLimiter](https://docs.spring.io/spring-cloud-gateway/reference/spring-cloud-gateway-server-webflux/gatewayfilter-factories/requestratelimiter-factory.html) | 网关内置限流机制 |
| [15] | [Bucket4j — Project README](https://github.com/bucket4j/bucket4j) | 多后端、应用级限流技术路径 |
| [16] | [全国标准信息公共服务平台 — JR/T 0185—2020](https://std.samr.gov.cn/hb/search/stdHBDetailed?id=A0A4877CF9037854E05397BE0A0ABEB0) | 标准的推荐性、现行状态及基本信息；适用条款以正式原文为准 |
| [17] | [IETF RFC 6585 — Additional HTTP Status Codes](https://datatracker.ietf.org/doc/html/rfc6585) | 429 的状态码定义 |
| [18] | [IETF RFC 9110 — HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) | Retry-After 值、重试条件与 HTTP 语义 |
| [19] | [IETF RFC 9112 — HTTP/1.1](https://www.rfc-editor.org/rfc/rfc9112.html) | 持久连接、复用、过载时主动断连的风险 |
| [20] | [Redis — TIME](https://redis.io/docs/latest/commands/time/) | 存储端时间源及墙上时间性质 |

**内部研究依据**：《全局限流架构治理与建设决策指南》v1.0（必要性门槛、SDK 边界、L0—L3 分级建设与投入产出）。历史版本沿革见附录 A。内部研究与公开文献均不替代特定银行业务系统的实测验证。

## 附录 A：版本修订记录（仅供版本追溯）

| 版本 | 核心变化 | 说明 |
|---|---|---|
| **v4.1（2026-10-30）** | 清理正文历史痕迹和作者提示；增加 L2 定量准入卡、统一时间源与时钟跳变、Deadline 与有界排队、重试预算/惊群、HTTP 连接复用、批联分时预算和按计量语义回补；把文档级复核附录改为项目评审表 | 不改变“必要性先行、最小协调域、局部优先、保证等级按场景证明”的总体研究结论 |
| v4.0（2026-10-30） | 由实现导向转为容量与风险治理研究；重排为必要性—范式—技术—场景—治理—验证闭环；删除支付伪代码和未经验证的阈值 | 强化 G1/G2/G3、混合故障态、复制丢写、对端计量点；引用一手工程资料 |
| v3.4 及此前 | 积累商业与开源实践、热点键、配额模型、存量衔接、严格额度相关风险分析 | 旧版端到端支付示例及其数值仅为当时的设计假设，不作为本报告实施依据 |

版本历史仅用于说明研究演进；**正文的术语、保证等级和五项前置条件均独立定义，可脱离历史版本使用**。

## 附录 B：项目接入全局限流架构评审自检表（Checklist）

本表用于**逐个受保护资源、逐条高风险规则**进行架构评审；需填写实际数值、证据链接和责任主体。表中示例数字不构成阈值推荐。适用的建设等级先按第三章确定，若选择 L0/L1 无须为接入率目标转为 L2。

### B.1 申请与资源画像

| 需填写的字段 | 项目填写值 / 证据链接 |
|---|---|
| 申请系统、业务域、规则 ID/版本、申请日期 | 待填 |
| 受保护的**真实物理资源**及资源责任人（具体到通道、连接池、数据库分片或系统） | 待填 |
| 资源安全容量与单位：正常/降容工况、测量窗口、P99、测试时间 | 待填 |
| 消费入口全量清单（网关、RPC、MQ、批处理、运维、应急、灾备）、最大并存数量与权重 | 待填 |
| 入口峰谷、突发倍数、流量倾斜与资源压力分布（监控截图/压测记录） | 待填 |
| 候选等级（L0/L1/L2/L3）、最小协调域和不采用较简单方案的原因 | 待填 |
| 关键业务 SLO、协议约束、可拒绝/可排队边界及风险接受人 | 待填 |

### B.2 六道评审关口

- [ ] **A 共享资源**：存在同一确定资源的跨执行点竞争；安全容量、降容容量有可信数据。
- [ ] **B 替代不足**：已提供同负载下 L0/L1、隔离、背压、扩容等最佳替代方案比较；均摊误差/倾斜有量化证据。
- [ ] **C 风险显著**：已给出不协调时的业务影响、故障或压测证据、明确的业务/风险负责人。
- [ ] **D 协调有效**：有关键吞吐、误拒、资源过载、P99、上界与长期成本的初步定量对照或可复核仿真；生产前必须补齐受控实测。
- [ ] **E 失联预案**：覆盖协调服务完全失联至少 5 分钟与最长租约/兜底周期（以较长者为准），逐规则选择 fail-open、受限本地或 fail-close；有业务/资源/运维共同会签。
- [ ] **F 保证闭环**：选定 G1/G2/G3；确认全量入口、资源计量点、分区/切主/扩缩容、回退与不可接受风险处理。

**决定（三选一，仅勾选一项）：**

- [ ] 退回 L0/L1 优先治理
- [ ] 允许受控 L2 PoC
- [ ] 经专项验收允许 L2 生产上线

**判定规则**：A—C 缺客观证据或 D 缺可量化收益假设，不得批准 L2 PoC；D 未完成真实验证或 E—F 存在不可接受风险，不得批准生产上线，不可用总评分抵消。

### B.3 规则与故障专项检查

- [ ] 计量对象、窗口、突发、累计配额、对端计量点、权威时间源和日切口径明确；时钟跳变、主备切换经演练。
- [ ] 执行点可信且无旁路；认证先于额度校验；资源键经过敏感信息保护，能审计来源和规则版本。
- [ ] 预算保底、借用、归还、租约重叠、旧主隔离、混合故障态、丢写及未知态已核算；保证等级有证据。
- [ ] 同步排队等待不透支上游 Deadline，保留足够下游处理余量；取消与超时后许可释放可证明。
- [ ] 429/503 与 Retry-After 的响应语义已与调用方对齐，客户端退避抖动、重试预算和交易幂等/未知态处理明确。
- [ ] 正常限流拒绝下连接可复用；连接数、连接建立速率、TLS 开销与恶意连接保护经过压力测试。
- [ ] 批联共用资源存在时，分时预算、联机负载反馈、旧租约清退、批任务恢复和跨日计量有明确规则。
- [ ] 按请求尝试计量的速率令牌原则上不回补、并发许可及时释放、累计配额的合同计量与对账口径已分别验证。
- [ ] 配置误发布、影子与正式规则隔离、回滚、硬约束应急开关、退出条件和责任人已落实。

### B.4 失联策略与签署

| 风险决策字段 | 填写要求 |
|---|---|
| 故障注入条件 | 失联持续时间、网络分区位置、租约剩余时间、切主与扩缩容工况 |
| 正常/异常策略 | 逐规则明确 fail-open / 本地静态份额 / fail-close；写清最大可承受超发、误拒和持续时长 |
| 实测结果 | 下游压力、业务成功率、误拒、超额、P99、恢复耗时、警报及回滚结果 |
| 不能关闭的前置条件 | 说明不投产、调整架构或下调保证等级的处置及期限 |
| 业务与风险责任人 | 签字、日期 |
| 资源/应用责任人 | 签字、日期 |
| 架构与平台评审人 | 签字、日期 |
| SRE/运维责任人 | 签字、日期 |
| 安全/合规会签（适用时） | 签字、日期 |

**文档与验收边界**：此表是架构评审模板，不证明任何银行系统已通过 PoC、灾备演练或生产验收。未填写的字段与未勾选的检查项不能被解释为“默认通过”。