从百万 QPS 到安全成交：抢票系统全链路限流与流量治理

1.1 先定义“百万 QPS”到底出现在哪里#

以热门演唱会开票为例，开票前后同一秒内可能同时出现活动页刷新、余票轮询、座位图加载、资格校验、锁票和下单请求。这里所说的“百万 QPS”，首先是到达边缘网络的 Offered Load（外部提供负载），而不是数据库每秒要完成一百万次库存事务。

一条请求链路中的流量应同时区分事件计数与窗口末存量：

这些指标必须按“层级 + 规则 + 资源”打标签。CDN 命中的请求在边缘属于 HandledHere，不会成为源站的 Admitted；在 Waiting Room 中等待的是用户会话，不是进入后端线程池的 HTTP 请求。因此，不能拿入口 QPS、源站 QPS 和数据库 TPS 做简单的一一比较。

还要先拆开三个经常被混用的概念：

• 限流器控制单位时间或同时在途的工作量，目标是保护系统容量。
• 虚拟等候室控制哪些用户可以进入、进入顺序以及放行速度，目标是把同步洪峰变成可控用户流。
• 库存事务通过条件更新、锁、版本号或其他一致性机制保证不超卖，目标是维护业务事实。

通过限流不代表一定有票，进入等候室也不代表获得库存；同样，数据库可以做到不超卖，却仍可能因为所有请求都参与竞争而被击穿。

1.2 全链路地图：每一层常用什么中间件#

生产系统通常不会从零手写每一个计数器，而是让成熟中间件承担通用能力，再用业务代码补足中间件看不到的语义。一次典型请求可以沿下面的路径流动：

1
Web / App
2
  ↓
3
权威 DNS / GSLB / Anycast / CDN
4
  ↓
5
DDoS 防护 / WAF / Bot Management / Waiting Room
6
  ↓
7
云 NLB/ALB、LVS、HAProxy 等四层或七层负载均衡
8
  ↓
9
NGINX / Ingress / Envoy Gateway / Spring Cloud Gateway
10
  ↓
11
Tomcat / Netty / Sentinel / Resilience4j
12
  ↓
13
Service Mesh / Dubbo / gRPC / HTTP Client
14
  ↓
15
资格、场次、票档、锁票、订单等业务服务
16
  ↓
17
Caffeine / Redis / Kafka / RocketMQ / RabbitMQ
18
  ↓
19
MySQL / PostgreSQL / 支付与其他第三方接口

第一章只说明各层“为什么要限、通常用什么”，后续章节再展开配置、算法和故障行为。

DNS、GSLB 和四层负载均衡首先解决“流量落到哪里”和“单个入口是否被连接打满”。它们可以按健康状态、地域和权重分配流量，也可限制连接或新会话速率，但此时通常还没有可信的用户身份和场次语义。越靠近边缘，判断越便宜、粒度越粗；越靠近业务，判断越精确、单次拒绝前已经消耗的资源也越多。

1.3 沿请求路径提前暴露后续技术#

1.4 用 Little’s Law 同时约束速率与并发#

只设置 QPS 阈值无法完整描述容量。稳定系统中，Little’s Law 给出：

其中：

• $\lambda$ 是平均到达或完成速率；
• $W$ 是请求在系统内的平均停留时间；
• $L$ 是平均在途数量。

假设到达速率不变，下游延迟从 20 ms 上升到 200 ms，平均在途请求会扩大十倍。如果线程池、连接池和队列没有相应余量，系统会先耗尽并发资源，再出现超时；客户端重试随后又提高 $\lambda$，形成正反馈。

所以每一层至少要同时维护两类预算：

1
速率预算：每秒允许开始多少新工作
2
并发预算：同一时刻允许多少工作占用资源

速率限制适合抑制突发和维持长期吞吐，并发限制更能直接响应下游延迟变化。Google SRE 对级联故障的分析也强调：服务应在过载时尽早、低成本拒绝请求，并分别在负载均衡层和单个任务上保护容量；单纯静态 Rate Limit 并不感知服务健康。Google SRE：Addressing Cascading Failures

对第 $j$ 个组件，必须把“每秒吞吐”和“同时占用”分开建模，不能把线程数、连接数和 TPS 塞进同一个取最小值公式。先定义：

• $R_{j,\text{safe}}$：组件在目标 SLO 和故障余量下的安全处理速率，单位是操作/秒；$R_{j,\text{reserved}}$ 是为回调、补偿和恢复任务保留的速率；
• $N_{j,\text{safe}}$：组件的安全在途槽位，单位是并发操作数；$N_{j,\text{reserved}}$ 是不可被普通入口占用的保留槽位；
• $k_j$：每个获准入口请求在组件 $j$ 产生的高分位或保守估计操作次数，包含扇出、分支概率与允许的重试；
• $m_j$：一个入口在途请求在组件 $j$ 同时占用的最大或保守估计槽位数。顺序执行三次访问会提高 $k_j$，但未必让 $m_j$ 变成三；并行扇出则可能同时提高二者。

支付等非必经阶段还要把“锁票到支付”的转化率与每笔支付尝试数计入对应的 $k_j$，不能假设每个业务意图都恰好调用一次每个依赖。

于是入口的稳态到达率和在途上限分别满足：

其中速率能力可由 CPU、下游吞吐和外部配额等同量纲结果取最小值；并发能力则由线程、连接、信号量和下游 in-flight 槽位取最小值。若组件 $j$ 的单次操作平均耗时为 $W_j$，还应使用 $L_j\approx\lambda_{\text{admit}}k_jW_j$ 交叉校验其并发占用。这样，下游变慢会先反映为在途压力，而不会被一个仍然“没超 QPS”的速率阈值掩盖。

安全系数 $0<\alpha_j,\beta_j<1$ 用于预留单机或单可用区故障、发布预热、扩容延迟和流量偏斜。若集群有 $n_{\text{inst}}$ 个同规格实例，要求故障 $f$ 个实例后仍可工作，则速率与并发容量应分别验证：

这些量必须来自相同 SLO 条件下的压测，而不是某次把服务压崩时看到的峰值。负载均衡偏斜、冷实例、长尾延迟和热 Key 会使平均分配假设失效，所以实例仍需本地并发闸门。

1.5 从最弱下游反推各层准入量#

限流阈值应从库存数据库、订单服务和支付等最弱约束向入口反推，而不是先拍一个“网关限 20 万 QPS”。可按下面的方向建立预算：

1
数据库安全事务能力 / 支付配额
2
  → 订单准入量
3
  → 锁票准入量
4
  → 资格校验量
5
  → API 网关业务预算
6
  → Waiting Room 新用户放行速度

设：

• $C_{lock}$ 为锁票服务安全处理能力；
• $p_{qualify}$ 为资格请求进入锁票阶段的比例；
• $a_{lock}$ 为一次锁票请求在内部产生的平均工作放大系数；
• $r_{retry}$ 为包括重试在内的额外放大比例。

则资格层准入至少应满足：

这里的比例必须由压测和历史数据估计，并在失败场景重新测量。故障时成功率可能下降，但每个失败请求仍会消耗鉴权、Redis 和数据库连接；此时不能因为“进入订单的比例下降”就误判上游可以放更多请求。

更稳妥的做法是为每种请求定义成本向量。例如普通活动查询消耗缓存读取，锁两张票消耗热点库存写、订单预创建和风控调用，支付回调则要求高优先级、低延迟。网关的“一请求一令牌”只能表达最粗成本，动态票数、热点程度和库存状态仍需业务层补充。

1.6 安全容量不是崩溃容量#

容量测试最终要得到的是一组带 SLO 的安全工作区间，而不是单个最大 QPS。阈值至少同时受以下信号约束：

• p95/p99 延迟是否仍在业务 Deadline 内；
• 错误率、超时率和主动拒绝率；
• CPU、GC 暂停、事件循环延迟；
• 工作线程、任务队列和在途请求；
• JDBC、Redis、HTTP 连接池等待时间与占用率；
• 数据库锁等待、热点行冲突和事务回滚；
• MQ Backlog、最老消息年龄和消费赶超时间；
• 故障一台实例或一个可用区后的剩余容量；
• 发布、扩容、缓存预热期间的额外余量。

当压测开始出现超时后，观测到的“完成 QPS”可能反而下降。Google SRE 将这种现象视为典型级联故障起点：一部分实例过载后退出，剩余实例承受更高负载，最终总吞吐低于正常容量。因此准入阈值必须落在延迟拐点之前，并通过本地保护防止负载偏斜把单个实例推过拐点。

1.7 三条贯穿全链路的控制线#

后续所有中间件能力都可以归入三条控制线，但同一组件未必同时实现三条线。

第一章给出的是全链路地图。接下来的客户端、边缘、网关和服务章节将逐层说明：中间件已经封装了什么、配置如何映射到底层机制，以及中间件不能覆盖时应把逻辑放在哪里。

2.1 客户端治理的目标与可信边界#

前端的价值不是“替后端挡住攻击”，而是减少正常用户无意产生的重复工作，并在拥塞时避免客户端形成重试风暴。常见来源包括：

• 用户连续点击“立即购买”；
• 搜索、筛选和座位图拖动的每次事件都触发请求；
• 多个组件同时读取相同活动数据；
• 页面切换后旧查询仍在执行；
• 浏览器恢复焦点或网络重连时大量查询同时刷新；
• 余票轮询周期过短且所有客户端时钟同步；
• WebSocket/SSE 断开后立即无限重连；
• SDK 对超时和 5xx 自动叠加重试。

这些行为每个用户只多发几次请求，乘以百万用户后却足以制造显著放大。客户端治理必须保留，但它不是安全控制：脚本可以直接调用 API，旧版本 App 可能不包含新逻辑，恶意客户端也可以伪造任何本地状态。

2.2 优先使用查询层和网络层中间件#

前端不必为缓存、去重和取消各写一套全局框架。可以按职责选择成熟库：

TanStack Query 会缓存查询，并在查询过期后按挂载、窗口重新聚焦或网络重连等事件自动重新拉取；官方也明确建议用 staleTime 和相应开关减少过度刷新。TanStack Query：Important Defaults 这类默认值适合一般应用，却可能在开票时刻把大量客户端同步唤醒。因此，使用中间件不等于接受所有默认配置。

2.3 防抖、节流和提交锁不能混用#

三种手段处理的是不同问题：

提交锁应是显式状态机，而不是单纯把按钮变灰：

1
IDLE
2
  └─ 用户确认 → SUBMITTING（生成 idempotencyKey）
3
       ├─ 明确成功 → SUCCEEDED
4
       ├─ 明确失败 → FAILED（允许用新业务意图重试）
5
       └─ 结果未知 → UNKNOWN（沿用原 Key 查询/重试，不直接创建新单）

如果客户端在超时后立即生成新 Key，再次提交同一订单，服务端无法识别它与上一次是同一业务意图。按钮锁只能减少重复操作，真正的防重仍由服务端幂等记录和订单唯一约束完成。

2.4 查询缓存与相同请求合并#

多个页面组件同时读取同一场次信息时，应共享同一个进行中的 Promise，而不是各发一次请求。SWR 官方将缓存、重新验证和请求去重作为内置能力；使用相同 SWR Key 的组件会共享同一个请求。SWR：Getting Started TanStack Query 同样由 Query Key 标识缓存和在途查询，并可以把 AbortSignal 交给查询函数。

关键不在于“用了缓存库”，而在于 Key 是否准确表达数据语义。例如：

1
["availability", eventId, showId, ticketTier, locale, authScope]

Key 少了 showId 会把不同场次错误合并；少了用户或权限范围可能把个性化数据泄露给其他视图；Key 加入每次都变化的时间戳又会完全失去去重效果。TanStack Query 也要求 Query Key 包含能够标识查询结果的可序列化变量。TanStack Query：Query Key 依赖

抢票场景可把数据分成三类：

• 活动介绍、场馆规则等稳定公开数据设置较长 staleTime，提前预取。
• “余票充足/紧张/售罄”等展示数据允许短暂陈旧，可短 TTL 缓存并后台刷新。
• 真实可售判断、锁票结果和订单状态不能只相信客户端缓存，必须访问权威服务。

还要审查查询库的自动行为。开票页通常不应让所有后台标签页按固定短周期刷新；窗口聚焦和网络恢复时可以加随机抖动，或者在活动服务下发的下一次允许刷新时间后再请求。

2.5 用 AbortController 取消已经失去价值的读请求#

浏览器原生 AbortController 可以中止 Fetch、响应体消费和流处理；Axios 也支持通过 signal 接入同一机制。MDN：AbortController、Axios：Cancellation

一个典型的“新查询覆盖旧查询”实现如下：

1
let currentController;
2

3
async function loadSeatArea(showId, areaId) {
4
  currentController?.abort();
5
  currentController = new AbortController();
6

7
  const response = await fetch(
8
    `/api/shows/${showId}/areas/${areaId}`,
9
    { signal: currentController.signal }
10
  );
11
  return response.json();
12
}

查询层中间件通常已经提供 AbortSignal。TanStack Query 会在查询变为过期或不活跃时中止该 Signal，前提是查询函数真正把它传给 Fetch/Axios。TanStack Query：Query Cancellation

取消有三个边界：

1. 浏览器停止等待不代表源站一定停止执行；请求若已到达服务端，数据库操作可能继续。
2. 取消适合搜索、筛选和座位展示等读请求，不能把“取消 HTTP”当成撤销锁票事务。
3. 取消必须与超时区分：前者表示结果已无业务价值，后者表示 Deadline 耗尽但服务端结果可能未知。

2.6 在应用层建立请求并发池#

HTTP/2 和 HTTP/3 可以在一个连接上并发多个请求，不能再依赖浏览器旧式的“每域名少量连接”间接限流。客户端可以建立有界并发池，并按业务价值调度：

1
高优先级：锁票结果查询、订单状态确认
2
中优先级：资格校验、当前场次基本信息
3
低优先级：推荐、广告、座位动画、埋点批量上报

当池已满时，低优先级任务应合并、取消或丢弃，而不是在内存中无界排队。并发上限也不应全局只有一个数字：图片/CDN 请求、业务 API 和第三方埋点应使用不同池，避免低价值请求占据关键通道。

客户端并发池保护的是单个终端及其链路，无法控制所有用户的总并发；它与网关、JVM 和数据库的服务端并发闸门是互补关系。

2.7 轮询、SSE 与 WebSocket 都需要抑制重连#

把余票轮询改成 SSE 或 WebSocket 能减少重复 HTTP 建连和无变化响应，但长连接并不会自动消除洪峰。百万连接断开后若同时重连，同样会形成尖峰。因此应配置：

• 首次重连指数退避并加入随机抖动；
• 服务端返回建议重连时间，客户端遵守上限；
• 页面进入后台后降低更新频率或暂停非关键订阅；
• 用版本号/游标恢复增量状态，避免每次重连都拉取完整座位图；
• 设置全局重试次数和总时间预算，超过预算转为手动刷新；
• 服务端已宣布售罄或活动结束后停止轮询。

对普通 HTTP 轮询，周期还应由响应动态调整：活动未开始时低频，临近开票按服务端允许值提升，收到 429 或 Retry-After 后立即退避，而不是用固定 setInterval 无条件发送。

2.8 重试预算与幂等键#

客户端只能对明确可重试的错误进行有限重试。GET 等幂等读取可以采用指数退避和 Jitter；锁票、下单等写请求必须先具备服务端幂等语义。AWS SDK 的标准重试模式使用重试配额 Token Bucket：失败重试会消耗令牌，成功后补充，令牌耗尽便快速失败，从而避免故障期无限重试。AWS SDK：Retry behavior

Idempotency-Key 的正确语义是“同一业务意图的多次传输使用同一个 Key”。IETF 的相关工作草案用于让 POST/PATCH 等非幂等方法具备故障容忍能力，但它不是客户端单方面生效的魔法 Header；服务端必须原子记录 Key、请求指纹、处理状态和结果，并规定过期时间。IETF：The Idempotency-Key HTTP Header Field

客户端重试至少遵守以下条件：

1
同一业务意图 → 复用同一 Idempotency-Key
2
不同请求体     → 不得复用同一 Key
3
结果未知       → 先查询或沿用原 Key 重试
4
收到 Retry-After → 不早于服务端指定时间重试
5
超过总预算     → 停止自动重试并向用户展示可恢复状态

Retry-After 可以与 429 或 503 一起告诉客户端最早的后续请求时间。MDN：Retry-After 服务端若只返回“系统繁忙”而不给可解析的错误码和重试提示，客户端很容易采取统一的短延迟重试，反而制造同步洪峰。

2.9 客户端层需要观测什么#

前端埋点至少要区分用户动作和实际网络请求，否则无法证明治理是否有效：

• 原始点击/输入事件数与真正发出的请求数；
• debounce/throttle 抑制数；
• 查询缓存命中和在途请求合并数；
• 主动取消、超时和错误分类；
• 每个页面的在途请求峰值与客户端排队时间；
• 首次请求数、重试数和 Retry Amplification；
• 轮询次数、SSE/WebSocket 重连次数及退避时间；
• 幂等 Key 复用次数和“结果未知”状态持续时间。

这些数据用于减少正常流量和定位体验问题，但服务端仍必须假设客户端完全不执行以上任何限制。

3.1 边缘层不是一个限流器，而是一组顺序执行的能力#

边缘网络通常同时承担缓存、安全检测、自动化流量治理和用户排队。以 Cloudflare 的产品顺序为例，DDoS Mitigation、WAF 和 Bot Management 等能力会先于 Waiting Room 处理请求；这很重要，因为机器人若先进入等候室，会占据合法用户的队列槽位。Cloudflare Waiting Room：产品交互说明

对抢票系统，更准确的做法是先按路径拆分。公开静态内容尽量直接由 CDN 完成，真正需要保护的购票路径再进入安全与排队链路：

1
公开且可缓存路径 → DDoS/WAF 检查 → CDN 命中后返回
2

3
购票动态路径     → DDoS/WAF/Bot/Rate Limiting
4
                 → Waiting Room 判断用户是否获得源站会话资格
5
                 → 仅获准请求进入后续网关/源站

不同厂商对 WAF、缓存和 Waiting Room 的具体执行相位可能不同，部署时应以所用平台的规则阶段为准，不能把上面的职责图当成固定产品执行顺序。

3.2 CDN：先把可缓存流量从源站剥离#

3.3 DDoS、WAF、Bot 和边缘 Rate Limiting 各自解决什么#

1
已验证的可信自动化访问 → 按业务需要 Allow 或独立配额
2
高风险且命中抢票接口   → Block / Managed Challenge
3
中等风险               → 更严格频率、二次验证、限制并发
4
正常会话               → 进入 Waiting Room 或业务网关

1
匹配范围：哪些 Host / Path / Method
2
计数 Key：IP、Cookie、Token 或其组合
3
计数条件：哪些请求或响应计入额度
4
处置动作：Log、Challenge、Block，以及持续时间

3.4 Waiting Room：限制的是进入业务系统的用户，而不是后端请求队列#

3.5 等候室、MQ 与库存资格的明确边界#

三者在时间上都可能表现为“等待”，但状态位置和保证完全不同：

边缘层应观测 CDN 命中/回源、WAF 各动作、Bot 分数分布、队列进入/退出、估算等待时间、放行用户的源站请求放大系数，以及 Waiting Room 放行后被网关再次拒绝的比例。最后一个指标过高，通常说明边缘阈值和源站容量没有正确对齐。

4.1 反向代理和 API 网关为什么都需要限流#

NGINX、HAProxy 等反向代理最适合在请求进入应用前做便宜、确定的保护：限制连接、按来源或路径平滑速率、阻止明显突发。API 网关则在路由、身份和请求属性可用后执行用户、活动、场次和接口级配额。

两层的推荐分工是：

1
反向代理：连接边界 + IP/Host/Path 粗限流 + 请求体等协议边界
2
API 网关：可信身份 + Route/API Group + 成本权重 + 分布式配额
3
业务服务：showId/ticketTier/库存状态 + 公平规则 + 资格令牌

如果所有请求都先调用远程认证服务，再做任何限流，认证服务会成为新的入口瓶颈。因此通常先用 NGINX/Envoy 本地规则按连接和来源做粗筛，再由网关本地验证 JWT 或读取缓存后的 Session 身份，最后做用户级配额。

4.2 NGINX：limit_req 与 limit_conn 的真实语义#

1
http {
2
    # 示例：按来源 IP 平均 5 r/s
3
    limit_req_zone $binary_remote_addr zone=per_ip:20m rate=5r/s;
4

5
    # 示例：按虚拟主机设置整体保护
6
    limit_req_zone $server_name zone=per_host:10m rate=1000r/s;
7

8
    server {
9
        location /api/tickets/ {
10
            limit_req zone=per_ip burst=10 nodelay;
11
            limit_req zone=per_host burst=200;
12
            limit_req_status 429;
13
            proxy_pass http://ticket_gateway;
14
        }
15
    }
16
}

1
http {
2
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
3
    limit_conn_zone $server_name zone=conn_per_host:10m;
4

5
    server {
6
        location /api/ {
7
            limit_conn conn_per_ip 10;
8
            limit_conn conn_per_host 10000;
9
            limit_conn_status 503;
10
            proxy_pass http://api_gateway;
11
        }
12
    }
13
}

4.3 API 网关的配额模型：先解析可信身份，再做层级预算#

抢票网关不应只有一个“全站 QPS”规则。一个请求通常要依次受以下预算约束：

1
区域/集群总预算
2
  → 活动 eventId 预算
3
  → 场次 showId 预算
4
  → API 操作预算（查询、资格、锁票、下单）
5
  → 用户/账号/设备预算
6
  → 单请求成本（票数、查询复杂度）

Key 必须来自可信来源：

• 登录用户使用网关验证后的 canonical userId，而不是客户端 Query 参数；
• 匿名用户使用边缘签发并校验过的会话/设备凭证，再辅以 IP；
• 服务间请求使用经过认证的 workload identity 或 API Key；
• Header 中携带的 showId 必须与路由参数/请求体校验一致，避免通过伪造 Key 逃逸配额。

如果身份解析失败，应进入明确的匿名桶或直接拒绝，不能把空 Key 当成“不限流”。认证本身也需要预认证 IP/连接保护和本地缓存，避免攻击者用无效 Token 耗尽远程鉴权服务。

4.4 Spring Cloud Gateway：把配置项准确映射到令牌桶#

Spring Cloud Gateway 的 RequestRateLimiter 过滤器通过 RateLimiter 实现判断请求是否放行，默认拒绝状态码是 429。KeyResolver 负责从 ServerWebExchange 中解析限流 Key；官方文档说明，默认找不到 Key 时请求会被拒绝，这一行为可通过配置调整。Spring Cloud Gateway：RequestRateLimiter

RedisRateLimiter 明确使用 Token Bucket，三个核心参数分别映射为：

配置片段如下，数值仅用于解释参数：

1
filters:
2
  - name: RequestRateLimiter
3
    args:
4
      key-resolver: "#{@verifiedUserKeyResolver}"
5
      redis-rate-limiter.replenishRate: 10
6
      redis-rate-limiter.burstCapacity: 20
7
      redis-rate-limiter.requestedTokens: 1

令牌桶以 replenishRate 维持长期速率，burstCapacity 允许预先积累的突发。requestedTokens 可让“锁票”比“普通查询”消耗更多固定令牌，但标准配置通常是某 Route 上的静态成本；若要根据请求中的购票张数动态扣费，需要自定义 RateLimiter、拆分 Route 或在业务层执行原子计费，不能把静态参数描述成自动理解业务成本。

RedisRateLimiter 把状态放在 Redis，使多个 Gateway 实例能够共享同一 Key 的额度，但这也把 Redis 延迟、Lua 执行、热 Key 和连接池变成准入路径依赖。百万 QPS 下不能默认每一个维度都对同一个 Redis Key 执行同步操作；本地桶、配额分片和全局额度分发应在分布式限流章节统一设计。

4.5 Sentinel Gateway：Route、API Group 与请求属性规则#

Sentinel 的网关适配器支持 Spring Cloud Gateway 和 Zuul。它提供两类核心抽象：

• GatewayFlowRule：针对 Route 或自定义 API 分组的网关流控规则；
• ApiDefinition：把多个 URL 模式组合成一个逻辑 API 组。

Spring Cloud Gateway 适配器会把 routeId 和自定义 API 定义视为 Sentinel 资源，并允许通过 Header、客户端 IP、Host 或 URL 参数做请求属性限流。Sentinel：API Gateway Flow Control

GatewayFlowRule 的主要字段不是模糊的“QPS 开关”，而是一组具体控制项：

这些字段及其支持范围可见 Sentinel 官方网关流控文档。Sentinel：网关流量控制

Sentinel Gateway 适合表达：

• /api/lock/** 这一组 API 的总体速率；
• 某个 Route 的快速失败或匀速排队；
• 按已校验 Header 中的渠道、来源或参数值分桶；
• 对特定参数模式应用更严格阈值。

它不自动完成“账号 + 设备 + 场次 + 剩余库存”的复合公平配额，也不会替代库存事务。更精细的 showId 热点和业务资格应在业务层建模；需要全局严格额度时还要使用 Sentinel Cluster 或其他全局配额方案。默认本地规则只约束当前实例，扩缩容时集群总允许量会随实例数变化。

4.6 Envoy：本地 Token Bucket 与外部全局 RLS#

Envoy HTTP Local Rate Limit Filter 对 Route 或 Virtual Host 应用 Token Bucket；无令牌时默认返回 429，并可通过运行时比例分别控制“参与判断”和“真正执行”，适合灰度或 Shadow 验证。默认桶按 Envoy 进程共享，也可按下游连接配置。Envoy：Local Rate Limit

当需要跨多个 Envoy 实例共享额度时，可以配置 Global Rate Limit Filter 调用外部 gRPC Rate Limit Service。Envoy 官方建议把本地限流与全局限流组合：本地 Token Bucket 先吸收巨大突发，外部服务再执行细粒度全局配额，从而避免全局 RLS 本身被每个请求击穿。Envoy：Global Rate Limiting

这个组合揭示了生产限流的重要模式：

1
本地快速判断（低延迟、允许小范围有界偏差）
2
  +
3
全局配额协调（跨实例一致、成本更高）

外部 RLS 不可达、超时或返回错误时，哪些接口 Fail-open、哪些 Fail-closed 必须按业务分类；该问题不能由“用了 Envoy”自动决定。

4.7 算法应跟随中间件和流量目标，而不是单独罗列#

如果中间件没有原生提供所需算法，应明确写成“自定义过滤器/外部限流服务”，而不是把它归入现有组件。例如 Spring Cloud Gateway 可以通过自定义 RateLimiter 接入滑动窗口，但 RedisRateLimiter 本身仍是令牌桶；NGINX limit_req 仍是漏桶，不因为配置了 burst 就变成通用 Token Bucket。

4.8 多级配额不能简单串联多个远程计数器#

“全站 → 活动 → 场次 → API → 用户”若每层都同步访问 Redis，会让一次请求产生多次准入 I/O；前面的桶已经扣令牌、后面的桶又拒绝时，还会出现额度如何返还的问题。常见改进方向包括：

• 全站/集群额度下发到网关本地桶，快速拒绝最外层突发；
• 活动和场次使用分片 Key 或配额租约，避免单一全局热 Key；
• 用户级短窗口由网关或 Redis 原子判断；
• 多个必须同时满足的额度在一个 Lua 脚本/专用 RLS 内原子检查和扣减；
• 真正库存感知的资格令牌由业务服务发放，不在通用网关重复造库存状态。

这部分属于分布式限流架构，而不是某个 Gateway YAML 就能完整解决的能力。

4.9 网关层的故障边界与观测#

每一种中间件都需要记录“判断过但未执行”和“真实拒绝”：

• NGINX：PASSED、DELAYED、REJECTED 及对应 Dry-run 状态；
• Spring Cloud Gateway：Key 解析失败、允许/拒绝、Redis 调用延迟和异常；
• Sentinel：通过 QPS、阻断 QPS、规则/资源/参数维度、排队超时；
• Envoy：enabled、ok、rate_limited、RLS 延迟、错误及运行时执行比例。

还要对以下边界做故障注入：

• CDN 之后无法恢复真实客户端 IP，是否错误地把所有用户合并到一个桶；
• NGINX 共享内存区耗尽时返回什么；
• Redis 或全局 RLS 变慢时，网关线程/事件循环是否被拖住；
• 规则配置缺失、版本不一致或动态推送中断时采用哪一版；
• 扩缩容后本地阈值是否导致集群总额度瞬间变化；
• 匀速排队的等待是否超过客户端 Deadline；
• 429/503 响应是否携带稳定原因码和可执行的重试提示。

网关层应尽早拒绝它确认无法处理的请求，但不能用长队列掩盖容量不足。已经进入 NGINX 或 Gateway 队列的请求仍占用连接、内存和等待时间；当估计等待超过 Deadline 时，快速拒绝通常比“排了很久再超时”更可控。

5.1 为什么网关限流后，JVM 仍然会过载#

网关通常按集群总预算放行，但实例真正承受的是本机流量和本机请求时长。沿用第 1 章的关系，当单机到达率为 $\lambda_i$、平均处理时间为 $W_i$ 时，本机在途请求约为：

即使 QPS 没有增加，只要库存服务、数据库或支付接口变慢十倍，同一实例的在途请求也会接近增长十倍。此时单纯设置一个固定 QPS 阈值并不能阻止线程、连接和堆内对象继续堆积。JVM 入口至少要同时观察两类信号：

• 速率信号：单位时间进入了多少请求，适合拦截明确的流量洪峰。
• 占用信号：当前有多少请求仍未完成，适合在下游变慢时保护线程池、连接池和堆内存。

因此，抢票核心接口一般采用“QPS 上限 + 在途并发上限 + 系统兜底规则”，而不是三选一。

5.2 Tomcat：连接、线程和队列只是容器边界#

对于 Spring MVC 一类阻塞式服务，Tomcat 是最先感受到单机压力的组件。其 HTTP Connector 的处理顺序大致是：请求占用处理线程；线程达到 maxThreads 后继续接受连接，直到 maxConnections；再多的连接进入受 acceptCount 影响的操作系统等待队列。Tomcat 官方文档明确区分了这三个阶段，并指出队列填满后连接可能被拒绝或超时。Apache Tomcat HTTP Connector

抢票系统更关心“在剩余 Deadline 内还能否完成”，而不是“请求能否暂时塞进队列”。设调用链剩余时间为 $D_r$，预估业务执行时间为 $T_s$，网络与序列化预算为 $T_n$，安全余量为 $T_m$，则本机允许的排队时间最多为：

如果右侧已经小于零，请求即使进入线程池也只会制造一笔注定超时的工作，应在入口快速失败。对锁票、创建订单等时效性很强的接口，短队列甚至零等待通常比大队列更安全；对报表、通知等低优先级任务，则应转入独立的有界执行器或异步队列，不能与核心请求共享线程预算。

虚拟线程能够降低“一个阻塞请求占用一个平台线程”的成本，但不会扩大 CPU、数据库连接、Redis 连接和热门库存行的容量。因此，即使采用虚拟线程，也仍然需要在依赖调用之前设置 Semaphore 或 Bulkhead。

5.3 Netty 与 WebFlux：保护少量 Event Loop，而不是增加线程#

Netty 使用 EventLoopGroup 处理连接和 I/O，典型服务端由负责接受连接的 boss 组与处理已接受连接的 worker 组构成。Netty 4.x User Guide Reactor Netty 也使用数量较少且固定的事件循环线程；Spring WebFlux 官方文档强调，响应式客户端采用 Event Loop 风格运行。Spring WebFlux Overview

这种模型的危险不是“业务线程不够多”，而是某个阻塞调用、长时间 CPU 计算或失控的回调占住 Event Loop，使一批连接同时失去处理机会。因此应遵循以下边界：

1. 在进入昂贵业务逻辑前执行非阻塞的并发准入。
2. JDBC、旧 SDK 等无法避免的阻塞调用应切到独立且有界的调度器，不能无限扩张 boundedElastic 或自建线程池。
3. 对出站 HTTP 连接池同时限制 active connection、pending acquire 和等待时长；连接池等待也必须计入请求 Deadline。
4. 持续监控 Event Loop pending task、连接池 pending、直接内存和响应延迟；仅观察 CPU 可能看不到事件循环被阻塞。

Tomcat 的线程上限和 Netty 的 Event Loop 数量都是资源边界，而不是完整限流策略。真正决定哪些请求能占用这些资源的规则，应放在 Sentinel、Semaphore 或业务准入层。

5.4 Sentinel：把接口声明为可治理资源#

Sentinel 的基本抽象不是 URL，而是“资源”。通过 Servlet、Spring WebFlux、Spring Cloud、Feign 等适配器，HTTP 路由或方法可以自动成为资源；必要时也可用 SphU.entry(resourceName) 显式包围一段代码。规则可以动态变更并实时生效。官方集成清单可见 Sentinel Open-Source Integrations。

对同一个锁票资源，可以同时配置多条规则：

1
// 示意代码：阈值必须来自目标环境压测，不能直接照抄固定数字。
2
FlowRule qpsRule = new FlowRule();
3
qpsRule.setResource("ticket:lock");
4
qpsRule.setGrade(RuleConstant.FLOW_GRADE_QPS);
5
qpsRule.setCount(lockQpsBudget);
6
qpsRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT);
7

8
FlowRule concurrencyRule = new FlowRule();
9
concurrencyRule.setResource("ticket:lock");
10
concurrencyRule.setGrade(RuleConstant.FLOW_GRADE_THREAD);
11
concurrencyRule.setCount(lockInflightBudget);

Sentinel 的 grade 可以选择 QPS 或并发线程数；并发线程模式本质上是轻量级 Semaphore 隔离，适合在依赖变慢时阻止更多请求占住线程。官方文档同时提醒，Circuit Breaker 的统计窗口不是并发上限，要限制并发必须使用线程数规则、Semaphore 或 Bulkhead。Sentinel Flow Control

5.5 按资源价值隔离，而不是全站共用一个池#

一个较合理的单机资源划分如下：

单机并发阈值不能从 maxThreads 直接抄取，而应反向受最弱依赖约束。为保持量纲一致，设 $N_{db}$、$N_{redis}$、$N_{down}$ 分别是本实例可用的数据库连接、Redis 在途操作和下游调用槽位；$m_{db}$、$m_{redis}$、$m_{down}$ 是一个入口在途请求同时占用的相应槽位数。入口并发上限应满足：

这里每一项的单位都是“入口在途请求数”。“每请求调用 Redis 三次”描述的是速率放大 $k_{redis}$，不能直接拿来除并发槽位；只有三次调用会并行占用三个连接时，才应令 $m_{redis}=3$。串行调用造成的在途增长，则通过第 1 章的 $\lambda k_jW_j$ 关系校验。

实际阈值还要扣除单机故障、发布预热、流量偏斜和运维恢复余量，并通过阶梯压测观察 p99、GC、线程池、连接池和拒绝率。容器参数定义“最多能堆多少工作”，Sentinel 规则定义“当前允许多少工作进入”；前者绝不能被当作后者的容量证明。

5.6 本章边界#

JVM 入口只负责保护本实例，不负责集群总配额，也不能判断某位用户是否已购票、某个票档还剩多少库存。Sentinel 热点参数和库存资格属于下一章；跨实例配额一致性属于第 9 章。这里的核心结论是：

网关用 QPS 保护集群入口，JVM 用并发和资源水位保护单机；队列不是容量，线程数也不是吞吐量。

6.1 从 URL 限流升级为业务资源限流#

锁票请求至少可能包含以下维度：

• eventId：活动维度，限制整个活动的业务流量。
• showId：场次维度，隔离某一热门场次。
• ticketTier 或 seatArea：票档、座区维度，保护热点库存桶。
• userId、实名证件摘要、设备标识：约束个人和关联主体的操作频率。
• channel、会员等级：执行渠道或权益预算，但不能绕开总容量。
• quantity：一次锁多张票的成本，不能始终按“一请求一令牌”计费。

因此，一个锁两张票的请求可以消耗两个库存成本令牌，而一次只读活动详情查询只消耗极低成本。对场次和用户的规则还应形成层级关系：

1
活动总预算
2
  └─ 场次预算
3
      └─ 票档 / 座区预算
4
          └─ 用户 / 证件 / 设备预算

上层额度保证资源总量不被击穿，下层额度保证单个主体不能独占资源。只做用户限流，成千上万不同用户仍可同时打爆同一个票档；只做场次限流，又可能让少量自动化账号抢走全部放行额度。

6.2 Sentinel 热点参数限流：保护高频 showId 和票档#

Sentinel Parameter Flow Control 能按传给资源入口的参数位置统计热点值，并允许为特定参数值设置独立阈值。例如，把 showId 作为第一个参数传入：

1
try (Entry entry = SphU.entry(
2
        "ticket:qualification",
3
        EntryType.IN,
4
        1,
5
        showId,
6
        ticketTier)) {
7
    return qualificationService.check(command);
8
}

随后可对 paramIdx = 0 配置通用场次阈值，并为某个特别热门的 showId 配置例外阈值。官方规则同时支持 QPS 和线程数维度。Sentinel Parameter Flow Control

但它有清晰边界：规则天然围绕某个参数位置和参数值工作，不会自动理解“同一实名证件关联多个账号”“一个设备切换多个用户”“会员与普通用户共享总池”等复合约束。可以把多个字段规范化成一个复合 Key 再传入，但高基数 Key 会增加本地统计状态，且多实例之间仍不是天然的全局严格配额。生产中通常采用：

• Sentinel 在每台 JVM 上快速拦截明显热点。
• Redis 或独立配额服务执行跨实例的复合业务额度。
• 数据库事务完成最终库存正确性。

三者分别负责本地保护、集群业务准入和最终事实，不能相互替代。

6.3 资格令牌：把“允许尝试锁票”与“已经有票”分开#

虚拟等候室令牌只说明用户获准进入业务系统，仍不足以直接访问库存写路径。业务层可以在资格校验后再签发一个短生命周期的锁票资格令牌，其最小载荷通常包括：

1
{
2
  "userId": "...",
3
  "showId": "...",
4
  "ticketTier": "...",
5
  "maxQuantity": 2,
6
  "issuedAt": "...",
7
  "expiresAt": "...",
8
  "nonce": "...",
9
  "policyVersion": "..."
10
}

设计时必须满足四个约束：

1. 不可篡改：由资格服务签名，库存服务验证受众、签名、有效期和规则版本，不能信任客户端自报字段。
2. 短时有效：过期后重新参与准入，避免大量旧令牌在流量回落时同时回放。
3. 一次性或有界使用：nonce 的消费必须原子化，重复提交只能复用同一业务结果，不能再次取得库存资格。
4. 不承诺库存：资格令牌只代表“可以尝试一次锁票”，最终仍由库存服务的原子条件更新决定成功或失败。

如果资格令牌的签发速度高于库存服务的实际处理能力，它只是把洪峰从入口搬到了令牌到期前；如果签发数直接等于剩余票数，又会因用户放弃、支付失败和票档选择变化造成利用率下降。因此签发速度应以库存写路径的安全吞吐为主，以剩余库存、持有释放率和成功率为修正信号，而不是机械地“一张余票发一个令牌”。

6.4 库存感知放行：控制的是尝试速率，不是缓存中的余票数字#

业务准入服务可以读取以下反馈：

• 库存服务 p99、在途请求和拒绝率。
• 数据库连接池等待、事务冲突和热点行锁等待。
• 某场次、票档的剩余库存与已预占库存。
• 锁定后放弃率、超时释放率和支付完成率。
• 当前有效资格令牌数和令牌消费速度。

控制器据此周期性调整场次或票档的令牌签发速率，实例本地令牌桶负责快速执行。反馈频率不宜与每个请求同步，否则热门库存的瞬时波动会引起准入阈值来回震荡。更稳妥的做法是设置最小、最大放行率、调整步长、观测窗口和迟滞区间：下游持续变慢时快速收紧，恢复时逐步放开。

这里使用的“剩余库存”必须区分两种语义：

• 页面展示可使用短 TTL 缓存或近似值，允许轻微滞后。
• 锁票结果必须读取或修改库存服务掌握的强一致事实，不能根据缓存页面宣告成功。

6.5 公平性不是一个 userId 限流 Key#

公平准入至少包含三类规则：

6.6 幂等、限流与防超卖是三条独立防线#

这三个概念经常被混为一谈：

一个可靠的幂等记录至少保存 idempotencyKey、调用主体、请求摘要、处理状态和最终结果。同一个 Key 携带不同请求体时必须拒绝，不能误复用旧结果；同一个 Key 的重试则返回正在处理或已经完成的同一结果。关于调用方请求标识、语义等价和晚到重试的设计取舍，可参考 AWS 对幂等 API 的公开实践。Making retries safe with idempotent APIs

但幂等记录通常建立在鉴权和部分业务解析之后，因此重复请求仍会消耗网络、CPU 和缓存查询，入口限流依然必要。

库存正确性则必须落在原子状态变更上。例如非选座票可以使用条件更新：

1
UPDATE ticket_inventory
2
SET available = available - :quantity,
3
    version = version + 1
4
WHERE show_id = :showId
5
  AND ticket_tier = :ticketTier
6
  AND available >= :quantity;

只有影响行数为 1 才算预占成功。选座场景则可对座位状态执行 AVAILABLE → HELD 的条件迁移，并通过唯一约束或状态机阻止同一座位出现两个有效占用。限流可以减少竞争和锁等待，却无法证明每次更新都满足库存不变量。

6.7 MQ 不能排队所有锁票请求#

把请求写入 MQ 并不等于系统拥有处理能力。若百万个未经资格筛选的锁票请求全部进入队列，会产生三个问题：库存早已售罄但大量旧消息仍在消费；用户无法获得及时且确定的结果；积压回放继续占用数据库和库存锁。正确顺序是：

1. 先完成用户、场次和票档准入。
2. 再对库存执行可判定的预占或生成有界业务任务。
3. 仅把允许异步的订单后处理、通知、日志或补偿工作写入 MQ。

消息队列的配额、积压和背压将在第 8 章讨论。本章只强调：业务限流决定“谁可以尝试”，库存事务决定“谁真正拿到票”。

7.1 生产中间件如何分工#

应用内组件能理解方法语义、幂等键和业务错误；Service Mesh 能以统一方式覆盖多语言服务。成熟系统通常两者并用，但必须指定每项能力的唯一责任层，尤其不能在浏览器、网关、应用客户端和 Sidecar 四层同时无预算重试。

7.2 Resilience4j：按下游建立独立的韧性组合#

Resilience4j 为 Java 提供可组合的 RateLimiter、Bulkhead、TimeLimiter、Retry 和 CircuitBreaker，Spring Boot 3 可通过 application.yml 为每个实例配置。Resilience4j Spring Boot 3

这些模块解决的问题不同：

• RateLimiter：限制本实例发往某个下游的调用速率。其本地许可不会自动形成集群总配额。
• SemaphoreBulkhead：用 Semaphore 限制并发执行数，适合已经有调用线程的同步请求。
• FixedThreadPoolBulkhead：使用固定线程池和有界队列隔离阻塞依赖。Resilience4j 官方明确提供这两种 Bulkhead 实现。Resilience4j Bulkhead
• TimeLimiter：为异步执行设置超时时间，并可尝试取消运行中的 Future；底层 HTTP、RPC 和数据库驱动仍必须配置自己的网络超时，否则取消上层 Future 不一定终止已发出的 I/O。Resilience4j TimeLimiter
• Retry：对明确可重试的瞬时错误执行有限次重试和退避。
• CircuitBreaker：根据慢调用率或失败率从 Closed 切换到 Open/Half-Open，避免持续调用明显失效的依赖。

尤其要避免把 Circuit Breaker 当作并发限制器。其滑动窗口只用于统计结果，即使窗口大小是 100，也可能同时放行超过 100 个调用；官方文档明确要求用 Bulkhead 限制并发。Resilience4j CircuitBreaker

1
全链路 Deadline
2
  └─ 有限重试策略
3
      └─ 每一次物理尝试：
4
          1. 检查剩余 Deadline
5
          2. 获取出站速率许可
6
          3. 获取该下游的 Bulkhead 许可
7
          4. 检查 Circuit Breaker
8
          5. 以不超过剩余时间的网络超时发起调用

7.3 Deadline：让下游知道这项工作何时已经没有价值#

Timeout 表示“这一跳最多等待多久”，Deadline 表示“整项用户请求最晚何时完成”。调用链每经过一层，都应从原始 Deadline 扣除已经消耗的时间和安全余量，再为下游设置更短的超时：

如果剩余时间不足以完成库存事务，就不应继续创建下游工作。gRPC 默认不会自动设置 Deadline，官方建议客户端显式配置；Java 和 Go 支持默认传播入站 Deadline，并在传播时转换为扣除已耗时的 timeout，以降低时钟偏差影响。Deadline 到期后，服务端应用仍有责任停止自己派生的后台任务。gRPC Deadlines

HTTP/Feign 没有统一的跨服务 Deadline 语义，通常需要通过受控请求头传播绝对截止时间或剩余毫秒数，并在每一跳重新校验。必须防止外部调用方伪造一个过长 Deadline；服务端应以自身接口上限截断。

7.4 Retry Budget：限制重试产生的附加流量#

重试只能处理短暂故障，不能治疗过载。假设三层调用都执行“原请求 + 3 次重试”，最坏情况下一个入口请求可以在最深层产生 $4^3=64$ 次尝试。Google SRE 因此建议：限制单请求重试次数、使用随机指数退避、只在一个合适层级重试，并建立进程级或调用方级 Retry Budget。Google SRE: Addressing Cascading Failures

Retry Budget 不只是 maxAttempts。常见定义是限定一个窗口内：

其中 $\beta$ 是允许由重试产生的最大比例。即使每个请求只重试一次，在大面积故障时也可能令流量接近翻倍；比例预算能在失败率升高时主动暂停重试。

Envoy 支持把并发重试数限制为 active request 与 pending request 的一定比例；配置 retry_budget 后会覆盖静态 max_retries 断路器。Envoy Circuit Breakers API gRPC 还提供 retryThrottling：失败会减少客户端令牌，成功以较小比例补回，令牌降到阈值以下时暂停重试。gRPC Retry

可重试条件必须白名单化：

• 可考虑重试：连接建立前失败、明确的瞬时 UNAVAILABLE、幂等读请求、携带可靠幂等键的写请求。
• 不应自动重试：参数错误、权限错误、业务库存不足、已触发限流、未知提交结果且没有幂等保障的写操作。
• 每次重试都重新检查 Deadline、Retry Budget 和下游并发许可，并使用指数退避与随机抖动。

7.5 Dubbo、gRPC 与 Feign：默认值不能想当然#

7.6 Envoy 与 Istio：在网络层统一实施出站边界#

Envoy 的上游 Circuit Breaker 可以限制每个 cluster 的：

• 最大连接数 max_connections。
• 最大 pending request 数 max_pending_requests。
• 最大在途请求数 max_requests。
• 最大并发重试数或比例型 retry_budget。
• 最大并发连接池数。

这些限制在代理数据面本地执行，按上游 cluster 和优先级配置；官方说明 worker 线程之间的状态为最终一致，因此竞争时可能有小幅超限。它们适合快速失败和向调用方施加背压，不是严格的全局配额服务。Envoy Circuit Breaking

Istio 则通过：

• VirtualService 配置路由级 timeout、retry 和重试条件。
• DestinationRule 配置连接池、负载均衡和 outlier detection，把持续失败的实例暂时移出负载均衡集合。

官方文档将连接池和异常点剔除都归入目标服务流量策略。Istio DestinationRule 应用侧 Circuit Breaker 与 Mesh 侧 outlier detection 不是一回事：前者判断某类调用是否继续，后者判断某个 Provider 是否仍应被选中。两者可以同时存在，但阈值要协调，避免应用已经熔断、Sidecar 又持续探测，或所有实例因相同短暂错误被同时摘除。

7.7 Load Shedding：先拒绝低价值工作#

当依赖已经过载，仅靠超时会让请求继续占用资源直到失败。调用方应在以下时机主动丢弃工作：

• 剩余 Deadline 已不足以完成调用。
• 对应下游 Bulkhead 已满。
• Retry Budget 已耗尽。
• Circuit Breaker 已打开。
• 下游明确返回过载或限流信号。

丢弃顺序应按业务价值预先定义：推荐、实时座位动画、非关键画像查询先停；库存释放、已锁票续单和支付回调保留独立容量。Fallback 也必须是低成本且语义真实的结果，不能在库存服务失败时伪造“锁票成功”，也不能让 fallback 再同步调用另一个同样脆弱的远程服务。

Envoy 还提供 Admission Control Filter，可根据滑动窗口内的成功率概率性拒绝请求，并设置开始拒绝的成功率、拒绝激进度和最大拒绝概率。Envoy Admission Control 这类自动 Load Shedding 更适合做经过压测和灰度的补充保护，核心业务仍要有确定的优先级与静态保底预算。

7.8 自适应并发：适合高级防线，不能未经验证直接接管核心流量#

固定并发阈值无法自动适应实例规格和下游延迟变化。Envoy Adaptive Concurrency Filter 会采样上游完成请求的延迟，用 minRTT 与当前 sampleRTT 的比值形成 gradient，并动态更新允许的在途请求数：

当实际延迟显著高于理想延迟时，gradient 下降并收紧并发；延迟稳定时，headroom 推动上限逐步探测增长。该控制器要求自己能够看到并限制发往目标 cluster 的全部相关请求；如果存在绕过 Sidecar 的流量，采样与控制都会失真。Envoy Adaptive Concurrency

成熟度必须如实标注：Envoy 当前 API 文档把该扩展标记为 unknown security posture，并要求只在上下游都可信的部署中使用。因此，固定连接/并发断路器和 Retry Budget 应作为生产基线；Adaptive Concurrency 更适合作为经过容量压测、Shadow 观测、单集群灰度和 Kill Switch 保护的高级能力，而不是未经验证就接管开票核心链路。Envoy Adaptive Concurrency API

7.9 一套不产生重试风暴的出站策略#

以库存服务为例，可以将策略收敛为：

1. 入口请求携带总 Deadline，库存调用只使用剩余预算。
2. 每个调用方实例为库存服务设置独立 RateLimiter 与 Semaphore Bulkhead。
3. Sidecar 再限制 cluster 的连接数、pending request、active request 和 retry budget。
4. 非幂等锁票写默认不在 RPC 框架层自动重试；确需重试时必须携带幂等键，并由唯一一层执行。
5. 慢调用率或错误率持续升高时打开 Circuit Breaker；并保留少量 Half-Open 探测，不用真实洪峰验证恢复。
6. Bulkhead 满、Deadline 不足或收到明确过载信号时立即停止派生低优先级 RPC。
7. 监控“逻辑调用数”和“物理尝试数”的比值，确保重试没有悄悄扩大 Offered Load。

最终原则是：

Timeout 限制等待时间，Deadline 限制整条调用链的生命期，Bulkhead 限制占用，Circuit Breaker 停止调用已失效依赖，Retry Budget 限制额外尝试。五者解决的问题不同，必须组合且只能由明确的一层负责重试。

8.1 Caffeine + Redis：缓存保护的目标是减少回源，不是制造另一份库存真相#

抢票链路中适合缓存的内容包括活动详情、票档说明、场馆布局、资格规则和近似余票展示；真实锁票结果、订单状态和支付结果则必须回到权威事务状态判断。尤其要区分：

• “页面展示仍有余票”可以容忍短暂陈旧。
• “这张票能否锁定”不能依据缓存中的近似值作最终决定。
• 缓存命中率再高，也不能替代数据库条件更新、库存服务原子预占或其他防超卖机制。

1
请求
2
  → Caffeine L1
3
  → Redis L2
4
  → Singleflight / 分布式重建门闩
5
  → 数据库或权威库存服务

1
cache_rebuild_concurrency(showId) <= C_rebuild
2
database_fallback_qps           <= Q_db_fallback

8.2 Kafka、RabbitMQ 与 RocketMQ：削峰之前先决定什么工作允许排队#

消息队列最容易被误解为“把百万请求都塞进去，系统就抗住了”。实际上，MQ 只是把已经获得准入、允许异步完成且队列等待不会破坏业务语义的工作，从生产速率平滑到消费速率。

适合异步化的通常是：

• 短信、站内信和推送。
• 行为日志、审计事件和统计聚合。
• 非实时营销任务。
• 已经完成库存预占后的后续编排，前提是预占凭证有明确有效期、幂等键和补偿协议。

不应直接无界入队的是：

• 尚未获得锁票资格的百万次尝试。
• 必须立即告知用户成功或失败、且超过等待期限便失去意义的请求。
• 没有幂等和过期语义的订单创建命令。
• 试图用“消息最终会被消费”代替库存原子预占的设计。

MQ 能保证的是消息传递与消费编排，不是库存事务。消息成功写入 Broker 不代表票已锁定，也不代表订单一定能在锁票有效期内完成。

1
业务准入速率
2
  ≠ Producer 向 Broker 的发送速率
3
  ≠ Consumer 从 Broker 拉取并占用下游的并发

1
queue_age_p99
2
consumer_lag
3
consume_success_rate
4
downstream_inflight

8.3 HikariCP、PgBouncer 与 ProxySQL：连接池是数据库的并发闸门#

数据库容量首先受 SQL、索引、事务和热点行影响，其次才是连接数。连接池的作用是复用连接并限制应用可同时占用的数据库会话，不是把 maximumPoolSize 调大就能提高数据库吞吐。

8.4 支付与第三方接口：限流、幂等和结果确认必须同时存在#

支付渠道、短信平台、实名校验和反作弊服务通常同时存在 QPS、并发、日配额和账号级配额。内部服务不能把全部应用实例各自按对方总配额配置本地桶，否则实例数乘上本地阈值后会整体超限。

生产实现应为每个 provider + account + operation 建立独立预算：

• 本地令牌桶吸收小突发，集群配额控制总量。
• HTTP 客户端连接池和并发信号量限制在途请求。
• 超时、熔断与 Retry Budget 阻止故障时无限重试。
• 创建支付、退款等写操作携带稳定幂等键。Stripe 官方文档也明确建议为创建或更新请求提供幂等键，以便连接错误后安全重试。Stripe Idempotent Requests
• 支付回调使用独立的保留容量，验签后按事件 ID 去重，不与普通查询共享限流阈值。

最重要的边界是：调用超时不等于支付失败。 客户端在未知结果下直接换一个幂等键重试，可能创建第二笔交易。正确流程是保留原业务单号和幂等键，通过异步查询、回调或对账确认最终状态，再执行补偿。

同理，本地订单事务和外部支付不应伪装成一个数据库原子事务。可以使用 Outbox、状态机或 Saga 记录“待支付、支付处理中、已确认、需补偿”等状态，但必须让重复回调、乱序回调和延迟回调都能得到幂等处理。

8.5 本章结论：依赖层的四条硬规则#

1. Caffeine 和 Redis 减少重复读取，但真实锁票仍由权威库存事务决定。
2. MQ 只承接已获准、可异步、未过 Deadline 的工作，不能吞入百万锁票尝试来替代业务准入。
3. HikariCP、PgBouncer 和 ProxySQL 建立连接边界，但无法修复慢 SQL、长事务和热点行竞争。
4. 第三方写操作必须同时具备共享配额、并发限制、幂等键和结果确认，超时不能直接解释成失败。

9.1 Spring Cloud Gateway RedisRateLimiter 的能力边界#

Spring Cloud Gateway 的 RequestRateLimiter 已封装 Redis 令牌桶实现。核心参数是：

• replenishRate：每秒补充多少令牌。
• burstCapacity：桶容量，即允许积累的最大突发。
• requestedTokens：一次请求消耗多少令牌，可用于加权请求成本。
• KeyResolver：决定按用户、IP、API Key、活动或其他身份生成限流 key。

官方文档明确说明该实现使用 Token Bucket，并在超限时返回 429。Spring Cloud Gateway RequestRateLimiter

它适合常规网关集群，但不能自动解决以下问题：

• 一个全站 key 会让所有请求集中到同一 Redis 分片。
• 按 userId 生成海量 key 虽然能分散负载，却不能自然表达严格的“全场总 QPS”。
• Redis 往返、Lua 执行和连接池等待仍在每次请求的关键路径上。
• KeyResolver 只定义计数维度，不提供配额控制面、版本灰度、租约下发或跨地域协调。
• Redis 故障时究竟放行还是拒绝，需要按接口另行设计，不能依赖一个全站默认值。

所以 RedisRateLimiter 是一种生产中间件实现，不是“接入之后即可自动承受百万 QPS”的容量证明。

9.2 Redis + Lua：原子性解决竞争，不解决热 Key#

令牌桶通常需要在一个逻辑步骤内完成：读取剩余令牌、根据时间补充、判断是否足够、扣减并写回。Redis 官方示例使用 Lua 原子执行这组操作，避免多个网关实例并发读取和更新产生竞态。Redis Token Bucket Rate Limiter

Lua 的价值是原子性，不是无限吞吐。脚本在 Redis 端执行时仍会占用对应分片的执行能力；脚本逻辑过长、返回数据过大或对单一 key 高频执行，都会让这个分片成为瓶颈。因此脚本应满足：

• 时间复杂度固定且很小，不做扫描。
• 只访问显式传入的 key。
• key 有合理 TTL，避免限流状态无限增长。
• 客户端设置命令超时、在途上限和降级策略。
• 监控脚本延迟、Redis CPU、热 Key、连接池等待和超时率。

1
rate:{show-123}:tokens
2
rate:{show-123}:timestamp

9.3 两类成熟的全局判定中间件#

9.4 更高吞吐的主线：本地令牌桶 + 带 TTL 的配额租约#

当逐请求访问中央服务成本过高时，应把全局限流从“每次请求申请一个令牌”改成“周期性向实例下发一批可消费配额”。

设区域在租约周期 T 内允许通过总量为 Q_region(T)，控制面将其拆分为：

其中 Q_i(T) 是网关实例的保底配额，Q_shared(T) 是供热点实例临时借用的共享突发池。实例收到带版本和 TTL 的租约后，在本地内存令牌桶中逐请求扣减，因此正常请求不再产生远程限流调用。

完整租约至少包含：

1
quota_key: region-us-west/show-123/lock
2
epoch: 1842
3
tokens: 50000
4
issued_at: 2026-08-17T18:00:00Z
5
lease_duration_ms: 1000
6
expires_at: 2026-08-17T18:00:01Z  # 审计与跨节点诊断使用
7
policy: fail-local

控制面负责：

• 根据数据库、库存和支付安全能力计算区域总预算。
• 按实例容量、近期负载和健康状态分配子配额。
• 维护规则版本、租约 epoch 和审计记录。
• 回收下线实例的后续配额，并为新实例提供冷启动保底值。
• 控制共享突发池，避免所有实例同时按最大突发运行。

数据面负责：

• 校验签名、配额 Key、租约版本和有效期；对每个 Key 记录 highest_seen_epoch。
• 一旦接受更高 epoch，立即围栏（fence）所有更低 epoch；旧租约即使墙上时钟显示尚未到期也不得重新生效。进程重启后必须从可信本地状态或控制面恢复最高 epoch，恢复前不得接受旧缓存租约。
• 收到租约时记录本地单调时钟 $t_{mono,recv}$，将控制面给出的 lease_duration_ms 一次性换算为 deadline_mono，并扣除网络延迟与时钟偏差安全量；逐请求判断只比较单调时钟。issued_at 与 expires_at 只用于审计、偏差告警和拒绝明显过旧的租约，不能直接驱动高频扣减。
• 定期上报使用量、拒绝量和剩余量。
• deadline_mono 到期后把本租约剩余令牌清零，再进入预先配置的本地保守策略，绝不能继续消费旧 epoch。
• 不在请求关键路径同步等待控制面。

Fail-local 的应急额度不能作为 fallback_tokens 随每张租约重复下发，否则攻击者或错误控制面可以靠反复发送过期租约重置额度。应急预算 $E_i$ 必须是独立、极小、有界的数据面配置，纳入容量评审；每个故障事件最多消耗一次，重复收到旧 epoch、重新拉取失败或进程重启都不能自动补满。只有控制面恢复并发布更高 epoch，或经过审计的 Break-glass 操作，才能重置它。核心写接口也可以把 $E_i$ 设为零，直接 Fail-closed。

这种设计牺牲的是瞬时全局精确性，换取数据面可用性和百万 QPS 下的常数级本地判定。必须显式计算网络分区、实例重启和租约未对账时的有界超发上限。例如可保守要求：

其中 $U_i$ 是故障发生时实例尚未上报、仍可能合法消费的有效租约余量；更高 epoch 生效后，旧 epoch 的余量必须归零，不能同时计入两代租约。$E_i$ 是上述独立应急预算，所有实例之和必须预先包含在数据库和库存的安全余量中。最终库存事务仍承担“不超卖”的正确性责任：限流保护容量，即使发生设计允许的短暂超发，业务事务也不能因此卖出不存在的票。

9.5 Envoy RLQS：值得借鉴，但当前仍不应作为默认生产基线#

Envoy Rate Limit Quota Service（RLQS）的协议正是“数据面周期上报使用量，服务端向各 Envoy 实例推送 quota assignment”的模型。配额可以带 TTL；首次尚未获得配额以及配额过期后，都可以配置允许、拒绝或使用回退值。Envoy RLQS Protocol

但是截至本文核验时，Envoy 官方仍将 Rate Limit Quota Filter 标记为 Work-In-Progress，明确说明仍在开发、尚未准备好投入使用；官方架构文档也说明目前没有开源参考 RLQS 实现。因此可以借鉴它的数据面上报、服务端动态分配、TTL 与过期行为设计，但不能把它描述成已经成熟可直接落地的开源生产方案。Envoy Rate Limit Quota — Work-In-Progress、Envoy Global Rate Limiting Overview

9.6 Fail-open、Fail-closed 与 Fail-local 必须按接口分类#

“限流器故障时是否放行”没有全站统一答案。至少应区分：

Fail-local 指在租约仍有效时继续消费其剩余额度；租约到期后旧 epoch 立即失效，只能消费第 9.4 节所述的独立、有界应急预算，耗尽后转为 Fail-closed。它不是无限 Fail-open，也不能靠重复加载旧租约补充额度。Envoy RLQS 的 no_assignment_behavior 和 expired_assignment_behavior、Sentinel 的 fallbackToLocalWhenFail 都提供了类似的中间件落点，但业务仍需决定每个接口的安全策略。Envoy RLQS Failure Modes、Sentinel Cluster Flow Control

9.7 分布式限流的生产选型#

最终原则是：全局精确、低延迟、无限可用三者不能同时免费获得。 抢票系统应让限流器提供容量保护和公平准入，让库存事务提供不超卖的最终正确性。

10.1 正确区分 429、503 与 202#

10.2 Retry-After 不是“请大家同一秒再来一次”#

Retry-After 可以是 HTTP 日期，也可以是等待秒数。服务端应给出不早于安全恢复点的值，客户端则要在此基础上增加随机抖动，避免全部用户在同一时刻重试。

推荐返回结构化原因，而不是只有一段字符串：

1
HTTP/1.1 429 Too Many Requests
2
Retry-After: 8
3
Content-Type: application/problem+json
4

5
{
6
  "code": "SHOW_LOCK_QUOTA_EXHAUSTED",
7
  "scope": "show",
8
  "action": "retry_later",
9
  "retryAfterSeconds": 8,
10
  "requestId": "01J5..."
11
}

客户端处理规则应是：

1. 尊重 Retry-After，再加入 Jitter。
2. 设置总重试次数和总时间预算。
3. 只重试明确可重试且幂等的操作。
4. 锁票或支付结果未知时，优先查询原请求状态，不创建新的业务请求。
5. 当重试预算耗尽时快速失败。AWS SDK 的标准重试策略就使用 Retry Token Bucket；令牌耗尽后不再重试，以减少故障期间的重试流量。AWS SDK Retry Behavior

10.3 超限后有六种动作，不只有“拒绝”#

后端 MQ 不能替代边缘等候室。等候室限制“多少用户获得进入业务系统的资格”；MQ 只能承接进入系统后确实允许异步化的工作。

10.4 按业务价值建立降级顺序#

抢票系统不应在过载时随机丢请求，而应提前建立优先级：

1
P0  支付回调、退款回调、已锁票用户的续单与结果查询
2
P1  锁票、提交订单、支付预创建
3
P2  资格校验、实名校验、风控核心判定
4
P3  余票查询、座位图局部刷新
5
P4  推荐、排行榜、实时动画、非关键统计

降级从 P4 向 P0 逐级推进：

• 先关闭推荐、动画和高频实时刷新。
• 再把余票查询降为短 TTL 快照。
• 收紧新用户资格发放，但保留已锁票用户的完成路径。
• 极端情况下暂停新锁票，仍保留支付回调、结果查询和补偿通道。

这也是为什么“所有接口共用一个网关阈值”不可取：当总阈值耗尽时，新的余票轮询可能抢走支付回调所需的最后容量。

10.5 恢复必须比降级更慢#

下游 RT 恢复并不代表系统已经恢复。此时可能仍有：

• MQ backlog。
• 数据库锁等待和连接池等待者。
• 客户端即将触发的重试。
• 过期缓存需要重建。
• 旧租约和新配额尚未收敛。

如果立刻恢复全部配额，积压回放、客户端重试和新流量会叠加成第二次洪峰。Stripe 的公开实践也强调，Load Shedder 在丢弃和恢复流量时都应缓慢变化，避免系统在健康与过载之间反复抖动。Stripe: Scaling Your API with Rate Limiters

推荐使用带滞回的状态机：

1
NORMAL
2
  → SHEDDING
3
  → STABILIZING
4
  → RAMPING_UP
5
  → NORMAL

进入降级可以快速，退出降级需要同时满足一段稳定窗口：

• p99 延迟和错误率连续低于恢复阈值。
• JVM in-flight、线程池和连接池水位回落。
• Redis、RLS 和配置版本稳定。
• MQ 最老消息年龄下降，而不是仅瞬时消费速率上升。
• 数据库锁等待和事务时长恢复。

随后以 5%、10%、20% 等阶梯逐步增加配额，每一步观察至少一个完整反馈窗口；任一核心指标再次恶化，回退到上一安全档。具体比例应由压测确定，不能在代码中拍脑袋写死。

10.6 本章结论#

429、503 和 202 分别表达调用方配额、服务过载和异步接受，三者不能互换。限流响应必须携带稳定原因码和合理的重试提示；降级必须按业务价值保留核心路径；恢复则必须结合积压、重试和缓存重建渐进放开。

11.1 Sentinel Dashboard 不是唯一规则事实源#

Sentinel Dashboard 可以实时查看资源并修改规则，但官方文档明确说明，Dashboard 下发的规则默认存储在客户端内存中，并建议通过动态规则数据源持久化。Sentinel Dashboard

生产上可以选择 Nacos 或 Apollo 作为规则控制面：

• Nacos 提供配置发布、读取、监听和 CAS 发布接口，客户端可以订阅 dataId + group 的变化；CAS 可避免操作者基于旧版本覆盖新规则。Nacos Java SDK
• Apollo 支持配置实时生效、发布版本管理、回滚、灰度发布、权限分离和操作审计，适合对高风险规则建立编辑—审核—发布流程。Apollo Project、Apollo Gray Release Guide

无论使用哪一种，中间件只负责存储和分发，规则本身仍需有稳定数据模型：

1
ruleId: ticket-lock-show-quota
2
version: 1842
3
scope: show
4
match:
5
  route: /api/tickets/lock
6
  showId: "*"
7
algorithm: token_bucket
8
rate: 12000
9
burst: 24000
10
requestedTokens: "ticketCount"
11
priority: P1
12
action: reject_429
13
mode: shadow
14
failPolicy: fail_local
15
effectiveAt: 2026-08-17T18:00:00Z
16
expiresAt: 2026-08-17T22:00:00Z

version、生效时间、失效时间、失败策略和 Shadow/Enforce 模式都不应隐藏在发布脚本中，而应成为规则合同的一部分。

11.2 一条规则的安全发布流水线#

推荐按以下顺序上线：

1. 静态校验：校验 schema、数值范围、时间窗口、算法参数和 key 模板。
2. 容量校验：确认所有实例最大配额之和不会超过数据库、库存和支付预算；确认保留容量没有被普通规则覆盖。
3. 冲突检查：检测全站、活动、场次、用户和接口规则的优先级与组合结果。
4. Shadow/Dark Launch：只计算“本应拒绝”的请求，不真正阻断。
5. 小流量灰度：按稳定实例哈希、机房或少量网关发布，而不是随机让同一用户在两个规则间跳变。
6. 逐级扩大：每一步比较拒绝率、核心成功率、公平性和下游水位。
7. 全量生效：记录发布人、审核人、规则 diff、版本和观察窗口。
8. 自动或人工回滚：达到错误拒绝率、配置不一致率或核心转化下降阈值时回退。

Stripe 在公开的限流实践中同样建议对限流器进行 Dark Launch、使用 Feature Flag 和 Kill Switch，并为触发次数建立告警与指标。Stripe: Scaling Your API with Rate Limiters

11.3 指标：从 Offered 到 Completed，而不是只看 429#

限流器最重要的是建立可守恒的流量账，而不是画一条只在稳态成立的箭头。对任一层、同一统计窗口，计数器与期初/期末存量至少应满足：

若经过异步队列，还应单独核对：

其中 WorkInSystem 包括排队中与执行中的请求；缓存命中并返回响应属于 HandledHere，不会成为下一层的 Forwarded。Rejected 应继续按协议、安全、配额和过载原因拆分；限流器判定错误则按实际 Fail-open、Fail-local 或 Fail-closed 结果进入相应去向，不能藏进 Admitted。重试是新的内部 attempt，但不是新的用户请求量，应以 attempt 维度单独记账；跨窗口对账必须带 WorkInSystem 和 Backlog 的存量变化，不能强行要求同一秒的 Arrivals 等于 Completed。

至少需要以下指标：

Micrometer 为 Java 应用提供 vendor-neutral 的 Counter、Timer、Gauge 和 DistributionSummary；Timer 同时记录次数与耗时，因此同一事件通常不必再重复增加一个计数器。Micrometer Reference、Micrometer Timers

Prometheus 负责抓取维度指标，Grafana 用于可视化。标签必须保持低基数：layer、rule_id、reason_code、region、route_group 可以作为标签；userId、完整 showId、请求 ID 不应直接进入常驻指标标签，否则时序数量会爆炸。需要定位单个请求时，应通过日志或 Trace 关联。

11.4 Trace 与日志：解释“为什么这个请求被拒绝”#

OpenTelemetry 通过上下文传播把跨服务的 Trace、Metric 和 Log 关联起来，适合追踪一次请求经过网关、JVM、库存、订单和支付的路径。OpenTelemetry Context Propagation、OpenTelemetry Signals

限流判定可以记录以下 Span Event 或属性：

1
traffic.layer          = gateway
2
traffic.rule_id        = ticket-lock-show-quota
3
traffic.rule_version   = 1842
4
traffic.decision       = rejected
5
traffic.reason_code    = SHOW_LOCK_QUOTA_EXHAUSTED
6
traffic.fail_policy    = fail_local
7
traffic.cost_tokens    = 2

但不应对百万 QPS 的每个正常请求强制全采样。可采用：

• 正常放行低比例采样。
• 503、限流器错误和版本不一致提高采样率。
• 429 按原因码分层采样，避免超限洪峰本身压垮观测系统。
• 指标保留全量聚合，Trace 用于解释样本，审计日志记录规则发布事实。

配置审计日志至少记录发布前后 diff、操作者、审批人、发布时间、灰度范围、回滚原因和最终生效实例数。它与请求 Trace 解决的是不同问题：前者回答“规则为何改变”，后者回答“请求为何被这一版本拒绝”。

11.5 告警应指向用户症状和保护失效#

Prometheus 官方告警实践建议优先针对用户可见症状，避免为每个内部原因都触发 Pager。Prometheus Alerting Practices

限流系统的高优先级告警应包括：

• 核心锁票或支付成功率下降。
• p99 延迟和 5xx 持续超出 SLO。
• Rejected 激增且下游并未过载，提示规则可能误杀。
• 下游已明显过载但 Rejected 仍为零，提示限流未生效。
• Fail-open/Fail-local 比例持续升高。
• 规则版本在实例间长期不一致。
• RLS、Token Server 或 Redis 的错误率和延迟升高。
• MQ 最老消息年龄、数据库连接等待和热点锁等待接近业务 Deadline。

“某个实例 CPU 瞬时 80%”更适合告警上下文；“用户锁票 p99 和失败率持续恶化”才是更直接的页面告警。

11.6 k6 压测：使用开放模型复现入口洪峰#

抢票开票是外部用户按时间到达的流量，系统变慢后，用户不会自动按服务器处理速度减少到达。因此压测应优先使用开放模型按到达率发压，而不是只固定虚拟用户数。

k6 的 constant-arrival-rate 和 ramping-arrival-rate 会独立于系统响应启动迭代，适合表达恒定 QPS、阶梯突增和开票同秒洪峰；官方文档明确将它们归为 open-model executor。k6 Open and Closed Models、k6 Ramping Arrival Rate

示例骨架：

1
import http from 'k6/http';
2
import { Counter, Rate, Trend } from 'k6/metrics';
3

4
const targetRate = Number(__ENV.TARGET_RATE || 100_000);
5
const preAllocatedVUs = Number(__ENV.PREALLOCATED_VUS || 20_000);
6
const maxVUs = Number(__ENV.MAX_VUS || preAllocatedVUs);
7

8
const businessCompleted = new Rate('business_completed');
9
const unexpectedFailure = new Rate('unexpected_failure');
10
const trafficDecisions = new Counter('traffic_decisions');
11
const admittedLatency = new Trend('admitted_latency', true);
12

13
export const options = {
14
  scenarios: {
15
    ticket_opening: {
16
      executor: 'ramping-arrival-rate',
17
      startRate: 10_000,
18
      timeUnit: '1s',
19
      preAllocatedVUs,
20
      maxVUs,
21
      stages: [
22
        { target: Math.floor(targetRate / 10), duration: '30s' },
23
        { target: targetRate, duration: '0s' },
24
        { target: targetRate, duration: '60s' },
25
        { target: 50_000, duration: '2m' },
26
      ],
27
    },
28
  },
29
  thresholds: {
30
    admitted_latency: ['p(99)<500'],
31
    unexpected_failure: ['rate<0.01'],
32
    dropped_iterations: ['count==0'],
33
  },
34
};
35

36
export default function () {
37
  const res = http.post(`${__ENV.BASE_URL}/api/tickets/lock`, '{}', {
38
    headers: { 'Content-Type': 'application/json' },
39
  });
40
  const decision = res.status === 429 ? 'rejected_429'
41
    : res.status === 503 ? 'shed_503'
42
    : res.status === 200 || res.status === 202 ? 'admitted'
43
    : 'unexpected';
44

45
  const admitted = res.status === 200 || res.status === 202;
46
  const terminalStatus = res.status === 200 ? res.json('status') : null;
47
  trafficDecisions.add(1, { decision }); // 只使用固定、低基数标签值
48
  businessCompleted.add(
49
    terminalStatus === 'LOCKED' || terminalStatus === 'SOLD_OUT'
50
  );
51
  if (admitted) admittedLatency.add(res.timings.duration);
52
  unexpectedFailure.add(decision === 'unexpected');
53
}

这只是说明建模方式，不是可直接照搬的容量目标。开放模型所需 VU 可以先按下式估算：

其中 $T_{iter,p99}$ 以秒计，$h$ 是脚本、网络抖动和发压机故障余量；若一次迭代发出多个 HTTP 请求，应先把目标 HTTP QPS 换算成迭代率。比如目标是 100 万次迭代/秒、p99 迭代耗时 0.5 秒，仅在途迭代就约需 50 万 VU，尚未计余量，这也说明百万 QPS 不能由一台压测机可信地产生。分布式发压时，应按每个发压分片承担的到达率分别核算 VU、CPU、端口、带宽和 TLS 成本。

dropped_iterations 表示 k6 因可用 VU 不足而没有按计划启动的迭代；做容量验收时它必须为零或满足事先声明的极小预算，否则“系统很快”可能只是发压端没有产生目标负载。business_completed、unexpected_failure 和带固定 decision 标签的 traffic_decisions 用于区分有效业务终态、预期 429/503 与真正异常；admitted_latency 只记录真正获准并返回 200/202 的响应。不要用全局 http_req_duration 直接证明核心路径 p99，因为大量快速 429/503 会把总体延迟分位数“美化”。k6 Threshold 是压测的通过/失败条件，可把 SLO、获准请求 p99、异常率、自定义业务完成率和 dropped_iterations 写入自动验收。k6 Thresholds

11.7 必须覆盖的故障演练矩阵#

Google SRE 将“测试到失效并继续测试”视为理解过载行为的重要手段；只有看到系统在资源耗尽、网络分区和依赖变慢时如何失败，才能确认限流器真正保护了系统，而不是只在正常压测中制造了漂亮的 429 曲线。Google SRE: Addressing Cascading Failures

11.8 最终验收不看“扛住百万 QPS”，而看流量账是否闭合#

一次合格验收至少应证明：

1. 每一层都按第 11.3 节的守恒式对账：Arrivals 的去向包含 HandledHere、Forwarded、Rejected、Failed/Cancelled 与窗口末存量；跨窗口以 WorkInSystem、Backlog 的期初期末差额闭合，重试 attempt 不冒充新用户请求。
2. Forwarded / Admitted 的速率与在途并发分别没有超过数据库、库存、MQ 和支付的安全预算，且扇出 $k_j$ 与并发占用 $m_j$ 已计入。
3. 核心路径在低优先级流量被丢弃时仍达到既定业务成功率与 admitted_latency p99；dropped_iterations 为零或处于事先声明的极小预算，证明发压端确实产生了目标负载。
4. 同一用户、设备、场次和票档的公平规则符合产品定义。
5. 限流服务故障时，每类接口按预定 Fail-open、Fail-local 或 Fail-closed 行为运行。
6. 配置能够 Shadow、灰度、回滚；控制面故障时 Break-glass 仍可签名下发、限定范围、双人审批、自动过期并完整审计。
7. 恢复过程没有因积压回放、缓存重建和同步重试形成第二次洪峰。

至此，全链路限流才从“若干中间件配置”变成一套可证明、可观测、可演练的容量控制系统。

全链路组件职责速查#