当前位置：网站首页>[ Kitex 源码解读 ] 请求重试

[ Kitex 源码解读 ] 请求重试

2022-08-09 15:55:00 【InfoQ】

Kitex

如果你还不了解 Kitex，可以看看《
[ CloudWeGo 微服务实践 - 01 ] 开篇
》。
如果你想参与 CloudWeGo 社区，给 Kitex 和其他组件贡献代码，可以看《
如何给 CloudWeGo 做贡献
》。

CloudWeGo 源码解读

Kitex 是 CloudWeGo 微服务中间件集合的一部分，已经把所有文章汇总到了《
CloudWeGo 源码解读
》。
null

请求重试

微服务不同于单体架构的是，跨服务的 RPC 调用很多都是都在不同机器之间。这样的架构方便了维护、扩展和分别迭代，但是同时这种架构方式也增加了网络间的不稳定因素，比如可能 CPU、网络、磁盘、内存、网卡等等硬件问题，或网络抖动、丢包、延迟等等客观原因都会带来调用失败的情况。

针对调用失败情况，微服务框架通常会有一定的重试机制，Kitex 中的重试其实包含了三种，这些内容也能在官方文档《
请求重试
》中找到：
  • 建连失败重试（框架会默认重试）
  • 超时重试
  • Backup Request

建连失败重试

框架会默认重试，这里参看上篇《
[ Kitex 源码解读 ] 熔断机制是如何实现的
》中关于“框架自动重试”的部分内容。

超时重试

错误重试的一种，即客户端收到超时错误的时候，发起重试请求。
代码示例可以参考 
kitex-examples/retry
。
注意
：
  • 确认你的服务具有幂等性，再开启重试
  • 超时重试会增加延迟

用法

fp := retry.NewFailurePolicy()
// 可选配置，重试次数, 默认2，不包含首次请求
fp.WithMaxRetryTimes(xxx)
// 可选配置，总耗时，包括首次失败请求和重试请求耗时达到了限制的duration，则停止后续的重试。
fp.WithMaxDurationMS(xxx)
// 关闭链路中止（下游整个链路都会正常重试，有重试放大风险，请慎重。）
fp.DisableChainRetryStop()
// 开启DDL中止
// 该策略是从链路的超时时间判断是否需要重试。
// 注意，Kitex 未内置该实现，需通过 retry.RegisterDDLStop(ddlStopFunc) 注册 DDL func，
// 结合链路超时判断，实现上建议基于上游的发起调用的时间戳和超时时间判断。
fp.WithDDLStop()
// 退避策略，默认无退避策略
fp.WithFixedBackOff(fixMS int) // 固定时长退避
fp.WithRandomBackOff(minMS int, maxMS int) // 随机时长退避
// 开启重试熔断
fp.WithRetryBreaker(errRate float64)
// 同一节点重试
fp.WithRetrySameNode()

cli, err := echo.NewClient(
"echo",
client.WithHostPorts("0.0.0.0:8888"),
client.WithFailureRetry(fp),
)
if err != nil {
log.Fatal(err)
}
for {
req := &api.Request{Message: "my request"}
resp, err := cli.Echo(context.Background(), req)
if err != nil {
log.Fatal(err)
}
log.Println(resp)
time.Sleep(time.Second)
}

Backup Request


注意

DisableChainRetryStop 
取消链路中止，使用该参数后则下游整个链路都会正常重试
，这有可能会导致重试放大，请根据情况慎重使用。
框架默认是关闭状态的
。

链路中止是指链路上的重试请求不会重试，比如 A->B->C，A 向 B 发送的是重试请求，如果 B->C 超时了或者配置了 Backup，则 B 不会再发送重试请求到 C。如果业务自行识别重试请求，可以直接决定是否继续请求到 C。简言之链路中止避免了 B 向 C 发送重试请求导致重试放大，业务自己控制可以完全避免 B 到 C 的请求。
原网站

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://xie.infoq.cn/article/49c70b806a0916078c1500653

边栏推荐

猜你喜欢

随机推荐