GolangRPC异常处理与重试方法

本文深入剖析了Golang中RPC（包括标准库net/rpc和主流gRPC）异常处理与重试的核心实践：强调必须精准识别错误类型——net/rpc需断言*rpc.Error，gRPC则必须用status.FromError()解包后按codes.Code判断；仅对codes.Unavailable、codes.ResourceExhausted等临时性错误实施带指数退避（100ms起始、≤3次）的智能重试，坚决规避字符串匹配、无差别循环或对权限错误/参数错误等永久性故障的无效重试；同时警示context超时与重试逻辑的协同陷阱，指出应为每次调用创建独立子context，并提醒流式RPC需逐帧校验错误且难以可靠重试——最终点明：真正的可靠性不靠客户端蛮力重试，而依赖服务端幂等设计与业务层状态一致性保障。

RPC调用失败时，err 通常不是 nil，但具体类型容易被忽略

Go 标准库的 net/rpc 和主流 gRPC（google.golang.org/grpc）在出错时都返回非 nil 的 error，但它们的底层类型完全不同：net/rpc 返回的是 *rpc.Error（含 Code、Msg 字段），而 gRPC 返回的是 *status.Status（需用 status.FromError() 解包）。直接用 errors.Is(err, xxx) 或字符串匹配 err.Error() 容易漏判或误判。

实操建议：

• 对 net/rpc：检查 err 是否为 *rpc.Error，再判断 Code 是否为 rpc.ErrShutdown 或自定义错误码
• 对 gRPC：必须先调用 status.FromError(err)，再用 .Code() 判断是否为 codes.Unavailable、codes.DeadlineExceeded 等可重试状态
• 避免用 strings.Contains(err.Error(), "timeout") —— gRPC 的超时错误信息可能不含 “timeout” 字样，且不同版本输出不一致

重试逻辑不能无条件套用 for + time.Sleep

简单循环重试会掩盖真实问题，比如服务端永久性错误（如参数校验失败、权限不足）或客户端配置错误（如错误的 endpoint）。重试只应针对临时性故障（网络抖动、服务瞬时过载、连接中断）。

实操建议：

• 仅对明确可重试的错误码重试：codes.Unavailable、codes.ResourceExhausted（限流）、codes.Internal（部分场景）、codes.Unknown（谨慎）
• 跳过不可重试错误：codes.InvalidArgument、codes.PermissionDenied、codes.NotFound、codes.AlreadyExists
• 使用指数退避（exponential backoff），而非固定间隔；起始延迟建议 100ms，最大不超过 2s，总重试次数建议 ≤ 3 次

func callWithRetry(client MyServiceClient, ctx context.Context, req *Request) (*Response, error) {
    var resp *Response
    var err error
    backoff := 100 * time.Millisecond
    for i := 0; i <h3><code>context.Context</code> 超时与重试必须协同设计</h3><p>常见错误是给整个重试过程设一个长 <code>context.WithTimeout</code>（如 30s），再在里面做 3 次各 5s 的 RPC 调用——这会导致最后一次调用可能只剩不到 1s 超时时间，还没发出去就被 cancel。更糟的是，重试中间的 <code>time.Sleep</code> 也计入 context 超时，进一步压缩可用时间。</p><p>实操建议：</p>

• 每次 RPC 调用都单独带子 context：ctx, cancel := context.WithTimeout(parentCtx, singleCallTimeout)
• 重试总耗时由外层逻辑控制（如计时器或重试次数），而非依赖单个 context 的 deadline
• 若使用 golang.org/x/time/rate 或类似限流器，注意它不感知 context 取消，需手动结合 select 检查 ctx.Done()

gRPC 流式 RPC 的错误处理和重试更复杂

Unary RPC 错误发生在一次调用结束时，而 streaming RPC（如 ClientStream）可能在 Send()、Recv() 或 CloseAndRecv() 任意环节出错，且错误后 stream 已关闭，无法继续复用。

实操建议：

• 流式调用中，每个 Send() 和 Recv() 都必须单独检查 err，不能只在最后检查
• 流式调用一般不支持“断点续传”式重试；若需可靠性，应在业务层设计幂等消息 ID + 服务端去重，而非依赖重试 stream
• 对服务器流（server streaming），一旦 Recv() 出错，应立即退出循环并关闭 stream；不要尝试在错误后继续 Recv()

真正难处理的，是那些看似可重试、但重试后行为不一致的情况——比如上游服务未实现幂等，或者重试触发了重复扣款。这类问题无法靠客户端重试逻辑解决，必须推动服务端补全幂等键和状态机校验。

到这里，我们也就讲完了《GolangRPC异常处理与重试方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！