Golang基于高阶函数构建自适应并发限流器

rate.Limiter 不能控制并发数，因其设计目标是限 QPS 而非 goroutine 数量；它基于令牌桶，不感知 goroutine 生命周期，瞬时并发仍可能打爆下游。

为什么不能直接用 rate.Limiter 控制并发数

rate.Limiter 的设计目标是控制「单位时间请求数」（QPS），不是「同时运行的 goroutine 数量」。它基于令牌桶，只看请求到达时间戳，不感知 goroutine 生命周期。比如你设了 rate.Every(100 * time.Millisecond), 5，100 个 goroutine 同时调 Allow()，前 5 个立刻通过——瞬时并发照样爆表，下游照样被打挂。

常见误用现象：压测时 CPU 占用不高，但 DB 连接池打满、延迟毛刺剧烈、超时陡增。这不是限流器“没生效”，而是它根本没在控并发。

• 真正控并发，得靠信号量语义：要么拿令牌才能启动，用完必须归还
• chan struct{} 是最轻量、零依赖、调度开销最小的选择
• 别指望 rate.Limiter 的 burst 参数来模拟并发限制——它只是允许透支的令牌数，不是并发槽位

用高阶函数封装 chan struct{} 并发限流器

核心是把「取令牌 → 执行 → 归还」这个流程抽象成一个函数，让业务代码只关心逻辑本身，不碰 channel 操作和 defer 管理。

示例实现：

立即学习“go语言免费学习笔记（深入）”；

func NewConcurrencyLimiter(n int) func(func()) {
    sem := make(chan struct{}, n)
    return func(fn func()) {
        sem <- struct{}{} // 阻塞直到有空槽
        go func() {
            defer func() { <-sem }() // 必须确保归还，哪怕 panic
            fn()
        }()
    }
}

使用方式简洁：

limit := NewConcurrencyLimiter(3)
for i := 0; i < 10; i++ {
    limit(func() {
        fmt.Printf("task %d startsn", i)
        time.Sleep(time.Second)
        fmt.Printf("task %d donen", i)
    })
}

• 返回的闭包是线程安全的，可复用、可传递、可组合
• 所有 goroutine 共享同一个 sem，天然满足“最多 n 个并发”语义
• panic 场景下仍能归还令牌，靠 defer + 匿名 goroutine 保证
• 别在循环里重复调 NewConcurrencyLimiter，会创建多个互不干扰的信号量

如何让并发限流器“自适应”

自适应的关键不是动态改 channel 容量（做不到），而是根据实时负载信号，**动态替换限流器实例**，并让新旧实例平滑过渡。

你需要两个东西：

• 一个负载评估函数，例如：func() float64，返回当前延迟 P95 或 CPU 使用率相对变化值
• 一个映射函数，例如：func(load float64) int，把负载信号转成目标并发数（带上下限和阻尼）

然后用原子指针管理当前生效的限流器：

var limiter atomic.Value
limiter.Store(NewConcurrencyLimiter(10)) // 初始值
<p>// 每秒检查一次，按需更新
go func() {
ticker := time.NewTicker(time.Second)
defer ticker.Stop()
for range ticker.C {
load := getLoad()          // 如：最近 10s 请求 P95 延迟
target := clamp(loadToN(load), 3, 20) // 下限 3，上限 20
limiter.Store(NewConcurrencyLimiter(target))
}
}()

注意：旧 goroutine 可能还在用老的 limit 闭包，但没关系——它绑定的是旧的 sem，新请求走新的闭包，自然就切过去了。没有锁、没有竞争、无感切换。

• 别试图用 sync.Mutex 锁住整个限流器再换，会成为性能瓶颈
• 不要在 handler 内部做 load 计算，采样必须前置、轻量、异步
• 阻尼很重要：若当前是 10，并检测到负载升高，别直接切到 3，建议每次最多调 20%（如 10→8→6）

容易被忽略的泄漏点和边界条件

最常出问题的地方不在算法，而在资源生命周期管理。

• defer func() { 必须写在 goroutine 内部，不能写在外层函数里——否则归还时机错乱
• 如果业务函数里启动了子 goroutine 且未等其结束就返回，令牌会被提前归还，导致并发失控
• channel 容量为 0 时，sem 会永久阻塞；容量为 1 时，看似“串行”，实则因调度不确定性仍可能短暂并发
• 不要用 context.WithTimeout 包裹限流器调用再期望自动取消——channel 阻塞不响应 cancel，得自己加 select 超时
• 测试时用 runtime.GOMAXPROCS(1) 无法复现真实并发行为，要跑在多核上

真正难的不是写出限流逻辑，而是让“替换”这件事对正在运行的 goroutine 透明，又不让归还逻辑被绕过。这两点漏掉任意一个，都会在高负载下缓慢泄漏或突然雪崩。