inboundqps限流在归档期失效，因其仅限制每秒请求数，无法约束单请求超长耗时；慢查询+大事务导致并发goroutine堆积、连接池耗尽，必须用concurrency并发数限流控制同时执行请求数。
微服务数据归档期间，Gin 服务最常因慢查询+长事务导致连接池耗尽、CPU飙升、请求堆积，单纯靠 QPS 限流（如 InboundQPS）基本无效——必须用 Concurrency 并发数限流兜底。
为什么 InboundQPS 限流在归档期完全失效
归档操作本质是 I/O 密集型任务：大量 SELECT + INSERT/UPDATE + 大事务提交。单个请求可能耗时 3–30 秒，但每秒仍只占 1–2 个 QPS。即使你设了 TriggerCount: 200，系统每秒仍能“合法”接收 200 个慢请求——10 秒后就积压 2000 个待处理 goroutine，数据库连接池瞬间打满，后续所有请求（包括健康检查）全部超时。
常见错误现象：
- 监控显示 QPS 正常（http_server_requests_seconds_sum P99 跳到 15s+
- PostgreSQL 出现大量
idle in transaction连接 - Gin 日志里反复出现
context deadline exceeded，但没触发限流中间件
根本原因：QPS 是“请求数/秒”，不是“并发数/秒”。它不感知请求执行时长，只管入口计数。
Concurrency 限流才是归档期的救命稻草
Concurrency 直接限制同时处于 handler 执行阶段的请求数量，无论这个 handler 是 200ms 还是 20s，只要没返回响应，就算一个活跃并发。
实操建议：
- 归档接口（如
POST /v1/archive/run）单独配置Concurrency规则，阈值设为数据库连接池大小的 70%（例如 pool=20 → 设TriggerCount: 14） - 务必搭配
Strategy: system.Adaptive（非BBR），因为Adaptive会根据当前 CPU/Load 自动下调并发阈值，比固定值更抗突发 - 在
WithBlockFallback中返回明确提示，例如：{"code":429,"msg":"archive service busy, please retry later"}，避免前端重试雪崩
示例规则片段：
{
MetricType: system.Concurrency,
TriggerCount: 14,
Strategy: system.Adaptive,
ScopeId: "archive-api",
}
别忘了给归档接口加 context 超时和取消传播
限流只是第一道闸，真正防止 Goroutine 泄漏的是主动超时控制。归档 handler 内部必须做三件事：
- 从
*gin.Context提取ctx，并传给所有 DB 查询、文件读写、HTTP 调用 - 设置合理
context.WithTimeout(c.Request.Context(), 120*time.Second)（不能用固定 30s，归档本身就要分钟级） - 在 SQL 查询前显式调用
db.WithContext(ctx)，否则context.Cancel对database/sql无效果
漏掉任意一点，限流拦截后残留的 goroutine 仍会持续占用资源，直到 DB 自身 kill 连接（通常要 5–10 分钟）。
真实生产中容易被忽略的细节
归档流量保护不是加个中间件就完事。最容易翻车的点是：Sentinel 的 Concurrency 统计基于 Gin 的 Context 生命周期，而如果你在 handler 里启动了 goroutine 去异步执行归档（比如用 go func(){}()），那个 goroutine 不受限流约束——它会绕过所有 Sentinel 检查，直接吃光内存。
正确做法只有两个：
- 归档逻辑全程同步执行（推荐），由
Concurrency和context.Timeout共同兜底 - 若必须异步，得把归档任务扔进带并发限制的 worker pool（如
ants库），且 pool size ≤Concurrency.TriggerCount，否则限流形同虚设
