[ Kitex 源码解读 ] 请求重试
Kitex
如果你还不了解 Kitex,可以看看《[ CloudWeGo 微服务实践 - 01 ] 开篇》。
如果你想参与 CloudWeGo 社区,给 Kitex 和其他组件贡献代码,可以看《如何给 CloudWeGo 做贡献》。
CloudWeGo 源码解读
Kitex 是 CloudWeGo 微服务中间件集合的一部分,已经把所有文章汇总到了《CloudWeGo 源码解读》。
请求重试
微服务不同于单体架构的是,跨服务的 RPC 调用很多都是都在不同机器之间。这样的架构方便了维护、扩展和分别迭代,但是同时这种架构方式也增加了网络间的不稳定因素,比如可能 CPU、网络、磁盘、内存、网卡等等硬件问题,或网络抖动、丢包、延迟等等客观原因都会带来调用失败的情况。
针对调用失败情况,微服务框架通常会有一定的重试机制,Kitex 中的重试其实包含了三种,这些内容也能在官方文档《请求重试》中找到:
建连失败重试(框架会默认重试)
超时重试
Backup Request
建连失败重试
框架会默认重试,这里参看上篇《[ Kitex 源码解读 ] 熔断机制是如何实现的》中关于“框架自动重试”的部分内容。
超时重试
错误重试的一种,即客户端收到超时错误的时候,发起重试请求。
代码示例可以参考 kitex-examples/retry。
注意:
确认你的服务具有幂等性,再开启重试
超时重试会增加延迟
用法
Backup Request
注意
DisableChainRetryStop
取消链路中止,使用该参数后则下游整个链路都会正常重试,这有可能会导致重试放大,请根据情况慎重使用。框架默认是关闭状态的。
链路中止是指链路上的重试请求不会重试,比如 A->B->C,A 向 B 发送的是重试请求,如果 B->C 超时了或者配置了 Backup,则 B 不会再发送重试请求到 C。如果业务自行识别重试请求,可以直接决定是否继续请求到 C。简言之链路中止避免了 B 向 C 发送重试请求导致重试放大,业务自己控制可以完全避免 B 到 C 的请求。
版权声明: 本文为 InfoQ 作者【baiyutang】的原创文章。
原文链接:【http://xie.infoq.cn/article/49c70b806a0916078c1500653】。文章转载请联系作者。
评论