Go 语言中实现 RPC 请求限流的核心是在服务端入口处控制并发或速率,常用方式包括:1. 使用 rate.Limiter 实现令牌桶 QPS 限流;2. 使用 sync.Mutex + 计数器限制并发数;3. 通过 gRPC UnaryInterceptor 统一管理限流策略。
在 Go 语言中实现 RPC 请求限流,核心是**在服务端接收请求前或调用链路入口处控制并发数或速率**,避免后端因突发流量过载而雪崩。不依赖外部中间件(如 Redis)时,可基于内存 + 标准库轻松落地。
适用于对单个 RPC 方法做 QPS 级别限制,适合流量相对平稳、需平滑削峰的场景。
rate.Limiter
limiter.Wait(ctx),阻塞等待令牌(或用 TryConsume 做快速失败)var myMethodLimiter = rate.NewLimiter(100, 20)func (s MyService) My
RPC(ctx context.Context, req pb.Request) (*pb.Response, error) { if err := myMethodLimiter.Wait(ctx); err != nil { return nil, status.Errorf(codes.ResourceExhausted, "rate limited") } // 正常处理逻辑 }
适用于严格控制同时执行的请求数(如数据库连接池敏感型服务),更偏“连接数”而非“QPS”维度。
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 实现统一限流
避免每个方法重复写限流逻辑,推荐生产环境使用的方式。
server := grpc.NewServer(
grpc.UnaryInterceptor(rateLimitInterceptor),
)限流不是“加了就完事”,要兼顾可观测性与弹性。
codes.ResourceExhausted,客户端可据此重试或降级sync/atomic 替代 mutex 做简单计数,减少锁开销