Go中RPC流控需限流与队列双管齐下：用rate.Limiter实现请求级限流，以buffered channel构建内存队列，结合context控制超时与取消，并采用429/ResourceExhausted等明确拒绝策略。
在 Go 中处理 RPC 流控，核心是避免服务被突发流量打垮，关键在于“限流”和“队列”双管齐下：限流控制单位时间请求数，队列缓冲瞬时高峰并平滑消费节奏。不靠框架黑盒，用标准库+轻量设计就能落地。
用 rate.Limiter 实现请求级限流
Go 标准库 golang.org/x/time/rate 提供了简单可靠的令牌桶实现，适合在 RPC 服务端入口（如 gRPC 拦截器或 HTTP 中间件）做粗粒度限流。
- 创建一个全局或按方法粒度的 Limiter，例如：limiter := rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示每 100ms 最多放行 5 个请求
- 在 handler 开头调用 limiter.Wait(ctx) —— 它会自动阻塞或返回 error，无需手动 sleep 或重试逻辑
- 对关键方法（如支付回调、用户登录）单独配置更严的速率，避免被非核心接口拖垮
用带缓冲 channel 构建内存队列
当限流后仍有短时堆积，需引入队列解耦接收与处理。用 buffered channel + worker pool 是最轻量、无依赖的方案。
- 定义 channel： reqCh := make(chan *Request, 100)，容量即最大积压数，超限可直接拒绝（返回 429）
- 启动固定数量 goroutine 消费：每个 worker 循环 并执行业务逻辑，天然支持并发控制
- 注意：channel 容量不是越大越好，过大会吃光内存；建议结合监控（如 len(reqCh)）动态告警
结合 context 控制超时与取消
RPC 场景中，排队等待本身也要设限，否则用户会长时间卡住。所有环节必须尊重 context。
- 接收请求时传入带 timeout 的 ctx，例如 ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
- 向队列发送前先 select 等待 ctx.Done()，避免 goroutine 泄漏
- worker 处理时也用该 ctx 调用下游（DB/HTTP），确保整条链路可中断
简单但有效的拒绝策略
限流和队列满时，别默默丢包或 panic，要明确反馈，方便客户端退避。
- 限流触发：返回 gRPC 状态码 codes.ResourceExhausted，HTTP 返回 429 + Retry-After 头
- 队列满：立即返回错误，不要阻塞写入 goroutine；可附带当前负载指标（如 “queue_f
ull=100/100”）辅助排查
- 避免重试风暴：提醒客户端指数退避，服务端也可加随机抖动（jitter）降低重试同步概率
基本上就这些。不需要引入复杂中间件，rate.Limiter + buffered channel + context 就能覆盖大多数 RPC 流控场景。重点不在组件多炫，而在每个环节都守住边界、及时反馈、可观察。
ull=100/100”）辅助排查