rate.Limiter 不能直接控并发，需设填充速率为0：rate.NewLimiter(0, 5) 才实现硬性并发上限5；令牌永不补充，须显式Done()释放槽位，等价带超时信号量。
rate.Limiter 不能直接控并发，得设填充速率为 0
很多人误以为 rate.NewLimiter(10, 5) 能限制同时最多 5 个请求在跑——其实它只保证「每秒最多放行 10 次，初始桶里有 5 个令牌」，瞬时仍可能 5 个 goroutine 同时拿到令牌并行执行。Operator 场景下，若下游是 etcd 或另一个服务，真正要防的是连接数/写入并发打满，不是 QPS。
正确做法是把填充速率设为 0：rate.NewLimiter(0, 5)。此时桶容量（第二个参数）就是硬性并发上限：令牌永不补充，每个 Wait() 成功后必须显式 Done() 才能腾出槽位。这等价于一个带超时的信号量。
- 别用
rate.Every(...)初始化——它只影响填充间隔，和并发控制无关 -
Wait()默认不超时，务必套context.WithTimeout(ctx, 100*time.Millisecond)，否则卡住会拖垮整个 informer 协程 - 如果限速目标是 HTTP 客户端调用（比如 Operator 调下游 service），建议封装进自定义
http.RoundTripper，而不是在每个 handler 里手写判断
按下游服务名或租户维度隔离限速器实例
Operator 往往要对接多个下游（user-service、billing-api、cluster-provisioner），共用一个 rate.Limiter 会导致相互干扰。比如 billing 接口突发压垮了限速器，user-service 的健康检查也被拦住。
应该用 sync.Map 缓存不同目标的限速器：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var downstreamLimiters sync.Map // key: "user-service/default", value: *rate.Limiter
func getLimiterFor(target string) *rate.Limiter {
if l, ok := downstreamLimiters.Load(target); ok {
return l.(*rate.Limiter)
}
l := rate.NewLimiter(0, 3) // 并发上限 3
downstreamLimiters.Store(target, l)
return l
}
- key 建议包含命名空间（如
"user-service/default"），避免跨 namespace 冲突 - 必须加 TTL 清理：长期不用的 target（比如被删掉的租户）对应的限速器会内存泄漏；可用后台 goroutine 定期扫描
time.Since(lastUsed) > 1h后删除 - 不要用普通
map[string]*rate.Limiter+sync.RWMutex—— 高并发下LoadOrStore性能差且易出错
集成到 client-go 的 Workqueue 里做统一限速
Operator 的核心是 Informer + Workqueue + 处理逻辑。把限速逻辑塞进 processNextWorkItem() 最自然：所有事件都经 queue 分发，限速点前置，不会漏。
关键不是自己造 queue，而是复用 workqueue.RateLimitingInterface 并配合 client-go 的限速参数：
- 初始化 queue 时用
workqueue.NewRateLimitingQueue(workqueue.DefaultControllerRateLimiter())，它自带指数退避，适合处理失败重试 - 但注意：它限的是「重试频率」，不是「调用下游的并发」。真正的下游调用限速还得在
processNextWorkItem里调limiter.Wait() - 切忌在
AddFunc/UpdateFunc回调里直接限速——这些函数运行在 informer 主线程，阻塞会导致整个事件队列卡死 - 每次
queue.Done(key)前，确保下游调用已完成，否则限速器的槽位不会释放
限速失效的典型现象和排查点
Operator 限速后还是把下游打挂了？常见原因不是代码没写，而是配置或语义理解偏差：
-
rate.NewLimiter(0, 5)设了并发 5，但实际看到 20 个 goroutine 在跑 → 检查是否在多个地方重复Wait()且没配对Done()，或者用了Allow()（它不占槽位） - 限速器生效了，但日志里大量
context deadline exceeded→Wait()超时太短，或下游本身延迟高，导致排队请求全超时；应结合下游 P95 延迟设 timeout，比如 2s - 重启 Operator 后限速“失忆” → 限速器是内存态，没持久化；但 Operator 场景本就不需要持久化，重点是启动时正确加载配置（如从 ConfigMap 读各下游的
max-concurrent） - 限速器实例被 GC 掉 → 确保它被全局变量或 struct 字段持有，别只在局部函数里 new 出来就扔掉
最易被忽略的一点：限速器必须和下游调用强绑定。比如你限了 HTTP client，并发压下去了，但忘了 controller 里还有直接调用 etcd client 的 List/Watch，那这部分流量完全绕过限速——得单独给 etcd.Client 加一层 wrapper。
