-
下游只是发布时抖了一下,我的服务却因为疯狂重试把它彻底打死、还让它久久无法恢复,我对着重试风暴和指数退避加抖动排查了大半天的复盘
一次本该轻描淡写的小故障:依赖的下游因发布短暂抖动几秒,本来加了重试就该平稳扛过。我也确实加了重试——失败就重试最多 3 次,以为很稳健。结果这"几秒小抖动"被重试放大成持续十几分钟的大故障:下游不但没恢复反而被打得更死,抖动结束后还久久缓不过来。百思不得其解:重试不是为了提高成功率吗怎么把下游搞死了?排查大半天才理解"重试风暴"这个反直觉陷阱:我的立即重试…- 0
- 0
-
重试把下游打死了:重试风暴避坑复盘
这是一次好心办坏事的典型事故,也是我对重试这个看似无害的机制彻底改观的一次。起因很小:我们依赖的一个下游服务某天出现了短暂抖动,有那么几秒钟变慢了少量请求超时了,这本来是件小事下游抖一下缓一缓通常几秒就自己恢复了。可那天它不仅没恢复反而被彻底打挂了一垮就是好久,连带把我们整个服务也拖垮了。事后复盘真凶让我大跌眼镜——把下游打死的不是别人,正是我们自己为了提高成功率而精心设计的失败自动重试机制。这就…- 2
- 0
-
重试与退避策略完全指南:从一次"重试把下游彻底打挂"看懂为什么失败不能无脑重试
2023 年我给一个交易服务接了好几个下游依赖调支付网关查库存发短信通知这些下游平时都挺稳但网络总会偶尔抖动某个下游也偶尔会超时一下第一版我处理得很顺手给每个下游调用都加上重试调用失败了就再试我设了重试 3 次每次失败后固定等 1 秒再来本地我把下游故意改成偶尔抛错一看重试确实生效了我心里很笃定重试嘛就是失败兜底的万能解药多试几次总能成可等它一上线一串问题冒了出来第一种最先把我打懵支付网关只是负载…- 4
- 0
-
大模型 API 重试与退避完全指南:从一次"上游抖一下、重试风暴把服务和上游一起打垮"看懂指数退避与抖动
2024 年我做一个接大模型 API 的服务要把用户的请求转发给上游的大模型。调用失败这件事我压根没多想。第一版我做得很省事调用失败了就重试套个循环失败就再调一次直到成功为止。本地开发时真不错本地网络稳上游也稳几乎不失败偶尔失败重试一次立刻就好了。我心里很踏实重试嘛不就是失败了再试一次多试几次总能成。可等这个服务真正上线扛起真实流量一串问题冒了出来。第一种最先把我打懵有一次上游大模型服务抖了几秒我…- 5
- 0
指数退避
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×