Golang RPC调用失败如何重试_Golang RPC重试机制设计

RPC调用失败时盲目重试会引发雪崩，必须结合超时、退避、熔断三要素；net/rpc需手动封装context超时，推荐迁移到原生支持context的gRPC，并通过拦截器统一实现带错误过滤与指数退避的重试逻辑。

RPC调用失败时直接重试会放大问题

Go 标准库 net/rpc 本身不提供重试机制，强行在客户端套一层 for 循环重试 Call 或 Go，往往导致雪崩：服务端超时未返回，客户端反复发请求，堆积更多连接和 goroutine。重试必须配合超时、退避、熔断三要素，否则不是容错，是攻击。

• 默认 rpc.Client 的底层连接是长连接，但单次 Call 调用没有内置超时 —— 必须手动包装 context.WithTimeout 或改用支持 contex

  

  t 的 RPC 框架（如 gRPC）
• 网络抖动时连续重试 3 次，不如等 100ms 后再试（指数退避），避免瞬时重试洪峰
• 若后端服务已全量 503，继续重试毫无意义；需结合错误类型判断是否可重试：io.EOF、net.OpError（连接拒绝/超时）可重试；rpc.ErrShutdown 或明确的业务错误码（如 "user_not_found"）不应重试

用 context 控制单次调用生命周期是重试前提

标准 net/rpc 的 Client.Call 签名不接受 context.Context，所以无法直接中断挂起的调用。可行方案只有两个：换框架，或自己封装带超时的调用逻辑。

• 推荐迁移到 gRPC：原生支持 context.Context，且 grpc.WithBlock() + context.WithTimeout() 可精确控制每次请求生命周期
• 若必须用 net/rpc，需在 dial 阶段设置连接超时，并用 time.AfterFunc + sync.Once 手动 cancel goroutine（不完美，但比无超时强）
• 示例伪代码：启动 goroutine 调用 client.Call，同时 select 等待 ctx.Done() 或结果 channel；一旦超时，关闭 channel 并标记本次失败

简单可靠的重试封装：backoff + error filter

重试逻辑不该散落在每个 Call 前后，应抽成可复用函数。关键点是区分“可重试错误”和“不可重试错误”，并控制退避间隔。

• 使用 github.com/cenkalti/backoff/v4 库，配置 MaxRetries: 3、InitialInterval: 100 * time.Millisecond
• 定义重试判定函数：func isRetryable(err error) bool { return errors.Is(err, io.EOF) || strings.Contains(err.Error(), "connection refused") || strings.Contains(err.Error(), "i/o timeout") }
• 不要重试 HTTP 状态码类错误（rpc 不暴露 status，但自定义错误字符串里含 "400" 或 "500" 就该跳过）
• 每次重试前检查 ctx.Err() != nil，防止重试过程本身被取消后还继续

gRPC 场景下更推荐用拦截器统一处理重试

如果你已在用 gRPC，别自己写重试循环 —— 利用 UnaryClientInterceptor 在拦截器里做重试，对业务代码零侵入。

• 拦截器内用 backoff.Retry 包裹原始 invoker 调用，传入自定义重试策略和错误判定函数
• 注意：gRPC 默认对非幂等方法（如 POST /update）禁用重试，需显式设置 grpc_retry.WithPerRetryTimeout 和 grpc_retry.WithCodes(codes.Unavailable, codes.DeadlineExceeded)
• 重试日志必须打全：第几次、退避多久、原始错误、是否最终成功 —— 否则线上出问题根本没法定位是重试掩盖了真实故障还是加重了负载

重试不是加个 for 循环就完事；真正难的是判断“此刻该不该重”，以及“重了之后系统整体会不会更糟”。很多 RPC 失败本质是下游已不可用，这时候最稳妥的操作，往往是立刻失败、上报告警，而不是默默 retry 到超时。