如何使用Golang实现RPC重试机制_Golang RPC失败重试与容错方法

go net/rpc 默认不支持重试，需手动封装 Call 方法实现带指数退避、错误过滤和连接管理的安全重试，生产环境建议迁移到 gRPC 或 Kitex。

Go net/rpc 默认不支持重试，必须手动封装

Go 标准库的 net/rpc（包括 jsonrpc 和 gob 编码）本身是无状态、无重试逻辑的。每次调用对应一次底层连接写入 + 读取响应，失败就直接返回错误，不会自动重连或重发。这意味着：网络抖动、服务短暂不可用、TCP 连接被对端静默关闭等情况，都会导致 client.Call() 立即失败，而你拿到的只是类似 read tcp 127.0.0.1:54321->127.0.0.1:8080: i/o timeout 或 connection refused 这样的底层错误。

所以重试必须由调用方自己控制——不是改服务端，也不是换框架，而是包装 *rpc.Client 的 Call 方法。

用带指数退避的循环 + 可重试错误判断实现安全重试

简单 for 循环重试容易打爆服务或客户端资源，必须加入延迟和错误过滤。关键点有三个：哪些错误值得重试、每次延迟多久、最多试几次。

• io.EOF、io.ErrUnexpectedEOF、net.OpError 中的 timeout 和 connection refused 通常可重试；rpc.ServerError（比如服务端 panic 返回的字符串错误）一般不可重试
• 使用指数退避（exponential backoff），例如从 100ms 开始，每次 ×1.5，上限设为 1s，避免雪崩
• 最大重试次数建议设为 3～5 次，再高意义不大，且可能掩盖真实故障

func RetryCall(client *rpc.Client, serviceMethod string, args interface{}, reply interface{}) error {     var err error     maxRetries := 3     baseDelay := 100 * time.Millisecond 
for i := 0; i <= maxRetries; i++ {     err = client.Call(serviceMethod, args, reply)     if err == nil {         return nil     }      if !isRetryableError(err) {         return err     }      if i < maxRetries {         time.Sleep(baseDelay)         baseDelay = time.Duration(float64(baseDelay) * 1.5)     } } return err
}
立即学习“go语言免费学习笔记（深入）”；
func isRetryableError(err error) bool { if err == io.EOF || err == io.ErrUnexpectedEOF { return true } if opErr, ok := err.(*net.OpError); ok { if opErr.Err != nil { if strings.Contains(opErr.Err.Error(), "timeout") || strings.Contains(opErr.Err.Error(), "connection refused") || strings.Contains(opErr.Err.Error(), "broken pipe") { return true } } } return false }
http-based RPC（如 net/rpc/jsonrpc）需注意连接复用与状态清理
如果用的是 jsonrpc，底层走的是 HTTP，而 Go 的 http.Transport 默认复用连接。但 net/rpc 不管理它，多次重试可能复用一个已失效的连接（比如服务端重启后 TCP 连接还留在 TIME_WAIT 状态），导致后续请求持续失败。这时不能只靠重试，还得主动刷新连接。

每次重试前，调用 client.Close() 再重建 *rpc.Client（适合低频调用）
或者更轻量：强制关闭底层 HTTP 连接，通过反射访问 client 的未导出字段 conn 并调用 Close()（不推荐，脆弱）
更稳妥的做法是改用长连接池管理，比如用 gorilla/rpc 或自建基于 http.RoundTripper 的重试 transport

简而言之：HTTP RPC 的重试比 raw TCP 更容易卡在“假连接”上，必须配合连接生命周期控制。
生产环境建议直接迁移到 gRPC 或 Kitex，标准 net/rpc 已不适用复杂容错场景
标准库 net/rpc 缺少中间件、超时传递、上下文取消、负载均衡、熔断等能力。即使你补全了重试，也很难优雅处理：重试期间上下文已取消、重试中服务彻底不可用需快速失败、不同方法需要不同重试策略等问题。
如果你正在设计新服务或重构旧系统：

用 gRPC + grpc-go 的 retry.Interceptor，支持 per-RPC 配置、状态码过滤、抖动退避
用字节开源的 Kitex，内置重试、熔断、降级，且兼容 Thrift/Protobuf
若必须坚持 net/rpc，至少把重试逻辑抽成独立 package，统一管控重试策略、指标上报和日志标记

重试本身不难写，难的是它和超时、取消、监控、服务发现搅在一起之后，边界开始模糊——这时候继续硬刚标准库，不如承认它已不是现代微服务的合适载体。