17370845950

Go RPC高并发优化核心是稳连接、控并发、减开销、松服务端：复用长连接池、限制goroutine并发数、选用Protobuf等高效序列化协议、服务端避免阻塞并合理注册方法。

Go 的 RPC（尤其是 net/rpc 和基于 HTTP 的 jsonrpc）默认是同步阻塞的，高并发下容易成为瓶颈。优化核心在于：减少单次请求延迟、提升连接复用率、控制并发资源、避免序列化/反序列化开销。以下几点是实战中见效快、易落地的关键技巧。

复用连接 + 使用长连接池

每次 RPC 调用新建 TCP 连接（尤其短连接）开销大，且受系统文件描述符限制。应主动复用连接：

• 客户端使用 http.Transport 配置连接池（适用于基于 HTTP 的 RPC，如 JSON-RPC over HTTP）：
  MaxIdleConns、MaxIdleConnsPerHost 设为合理值（如 100），IdleConnTimeout 建议 30s；
• 自定义 rpc.Client 时，传入已建立的 *http.Client 或复用 net.Conn（如用 rpc.NewClientWithCodec + 自定义 ClientCodec）；
• 避免在高并发循环中反复调用 rpc.Dial 或 rpc.DialHTTP，改为初始化一次连接池或共享 client 实例。

控制并发数 + 避免 Goroutine 泛滥

无节制启 Goroutine 发起 RPC 请求，会快速耗尽内存和调度器压力，反而降低吞吐。需主动限流：

• 用 semaphore（如 golang.org/x/sync/semaphore）或带缓冲 channel 控制最大并发请求数（例如 50～200，视服务端承载能力而定）；
• 配合 context.WithTimeout 或 context.WithDeadline 设置单次 RPC 超时（建议 ≤ 1s），防止慢请求拖垮整体；
• 慎用 go rpcClient.Call(...) 直接发请求，优先走统一调度层（如 worker pool）做排队与熔断。

减少编解码开销 + 选对序列化协议

默认 gob 效率尚可但不跨语言；JSON 易读但解析慢、内存占用高。高并发场景应优化：

• 服务端与客户端协议一致前提下，优先选用 Protocol Buffers（gRPC） 或 FlatBuffers，序列化/反序列化性能比 JSON 高 3–10 倍；
• 若必须用标准 net/rpc，可实现自定义 ServerCodec/ClientCodec 替换默认 gob，接入更轻量编码器（如 msgpack）；
• 避免在参数中传递大结构体或原始字节切片，考虑分页、字段裁剪或 ID 引用代替嵌套数据。

服务端优化：避免阻塞 + 合理注册方法

服务端性能常被忽略，但它是并发瓶颈的终点：

• RPC 方法内禁止阻塞操作（如同步 DB 查询、未设超时的 HTTP 调用），应转为异步或使用带上下文的非阻塞客户端；
• 注册方法时避免全局锁竞争，不用 rpc.Register 动态注册热更新，推荐启动时一次性注册；
• 对高频低耗方法（如健康检查、计数器），考虑绕过 RPC 框架，直接暴露 HTTP handler 提升效率。

基本上就这些。Golang RPC 高并发不是靠堆 Goroutine，而是靠稳连接、控并发、减开销、松服务端。用好 context、连接池、限流器和高效 codec，QPS 提升 2–5 倍很常见。