Go 语言中实现 RPC 请求限流的核心是在服务端入口处控制并发或速率，常用方式包括：1. 使用 rate.Limiter 实现令牌桶 QPS 限流；2. 使用 sync.Mutex + 计数器限制并发数；3. 通过 gRPC UnaryInterceptor 统一管理限流策略。
现令牌桶 QPS 限流；2. 使用 sync.Mutex + 计数器限制并发数；3. 通过 gRPC UnaryInterceptor 统一管理限流策略。在 Go 语言中实现 RPC 请求限流，核心是**在服务端接收请求前或调用链路入口处控制并发数或速率**，避免后端因突发流量过载而雪崩。不依赖外部中间件（如 Redis）时，可基于内存 + 标准库轻松落地。
使用 golang.org/x/time/rate 实现令牌桶限流
适用于对单个 RPC 方法做 QPS 级别限制，适合流量相对平稳、需平滑削峰的场景。
- 在服务注册前，为每个需要限流的 RPC 方法初始化一个
rate.Limiter - 在 handler 或 middleware 中调用
limiter.Wait(ctx)，阻塞等待令牌（或用TryConsume做快速失败） - 示例：每秒最多处理 100 个请求，允许最多 20 个请求瞬时突发
var myMethodLimiter = rate.NewLimiter(100, 20)func (s MyService) MyRPC(ctx context.Context, req pb.Request) (*pb.Response, error) { if err := myMethodLimiter.Wait(ctx); err != nil { return nil, status.Errorf(codes.ResourceExhausted, "rate limited") } // 正常处理逻辑 }
使用 sync.Mutex + 计数器实现并发数限制
适用于严格控制同时执行的请求数（如数据库连接池敏感型服务），更偏“连接数”而非“QPS”维度。
- 定义全局计数器和互斥锁，进入 handler 时加锁递增，退出时递减
- 超过阈值直接返回错误，不阻塞，响应更快
- 注意：需确保 defer 正确释放计数，尤其在 error early return 时
var (
activeCalls int
callMu sync.Mutex
)
const maxConcurrent = 50
func (s MyService) MyRPC(ctx context.Context, req pb.Request) (*pb.Response, error) {
callMu.Lock()
if activeCalls >= maxConcurrent {
callMu.Unlock()
return nil, status.Errorf(codes.ResourceExhausted, "too many concurrent calls")
}
activeCalls++
callMu.Unlock()
defer func() {
callMu.Lock()
activeCalls--
callMu.Unlock()
}()
// 处理业务逻辑}
结合 grpc-go 的 UnaryInterceptor 实现统一限流
避免每个方法重复写限流逻辑，推荐生产环境使用的方式。
- 编写一个通用的 unary interceptor，在其中根据 method name 匹配不同限流策略
- 将 limiter 实例按 method 缓存（如 map[string]*rate.Limiter），首次访问初始化
- 拦截器中统一处理限流失败、打日志、上报指标（如 Prometheus counter）
server := grpc.NewServer(
grpc.UnaryInterceptor(rateLimitInterceptor),
)注意事项与进阶建议
限流不是“加了就完事”，要兼顾可观测性与弹性。
- 限流触发时，返回标准 gRPC 状态码
codes.ResourceExhausted，客户端可据此重试或降级 - 避免在限流器中做耗时操作（如网络请求、磁盘 IO），否则反而拖慢整个链路
- 高并发下考虑用
sync/atomic替代 mutex 做简单计数，减少锁开销 - 如需集群级限流（跨多个实例），需引入 Redis + Lua 或专用限流服务（如 Sentinel），纯内存方案仅限单机
