01｜SDK超时重试：概念、重要性与常见场景
大家好，我是老赵。今天开始咱们正式聊SDK超时重试这个话题。
先问个问题：你写代码的时候，有没有遇到过这种情况——调用外部SDK，网络稍微一抖，整个请求就挂了？或者更狠的，一条请求超时，连锁反应导致你的服务也跟着雪崩？
如果你遇到过，那恭喜你，你来对地方了。这门课就是帮你把这套“坑”彻底踩平。
什么是超时重试？
说白了，超时重试就是：调用接口没在规定时间内收到响应，我就再试一次。
注意，这里有两个关键点：
- 超时——请求超出了你设定的等待时间
- 重试——再发一次相同的请求
看起来简单吧？但实际做起来，坑比想象的多。我曾经在项目里见过一个同事，直接把重试写在catch里，没有任何延迟。结果下游服务刚好在重启，一秒内收到几千次重试请求……嗯，那场面，大家懂的都懂。
核心概念表格｜超时 vs 重试
| 概念 | 含义 | 我常用的方式 |
|---|---|---|
| 连接超时 | TCP握手超过设定时间 | 200ms-500ms，不等待 |
| 读取超时 | 已经连接上，但响应迟迟不来 | 1s-5s，根据接口响应速度定 |
| 重试次数 | 最多尝试调几次接口 | 通常3次，最多不超5次 |
| 重试间隔 | 两次重试之间等多久 | 指数退避，初始100ms起 |
你想想看，如果每次超时就无脑重试，跟当年那些“刷新F5键”的人有什么区别？
为什么必须聊超时重试？
说白了，在互联网环境下，网络是不稳定的。你调一个SDK，中间可能经过：你的进程 → 虚拟机 → 物理机 → 交换机 → 负载均衡 → 目标容器 …… 这条链路上任何一环出问题，都可能超时。
而且，SDK调用往往不是你一个人的事。我手头一个项目，依赖了7个第三方SDK。一旦其中一个超时不处理，整个请求链路就断掉了。我以前做过一个文件上传系统，外部存储SDK偶尔网络抖动，500个请求里大概能抖掉3-5个。听起来不多吧？但用户感知就是“上传失败”。加了重试之后，成功率从99.2%干到了99.99%。
我个人的一个习惯：所有对外调用，包括数据库、消息队列、缓存、第三方API，只要涉及网络，我都默认加上超时和重试策略。宁可提前设计好，别等线上告警再临时救火。
还有一个更严重的问题——超时不重试引发的雪崩。
假设你的服务A调服务B，B超时。如果不重试，A的线程就一直挂着等。等的时间越长，A的线程池越容易被占满。结果新请求进不来，服务A也瘫了。反过来，如果加了合理的重试（带退避、带熔断），整个系统反而能撑住瞬间的抖动。
哪些场景最需要超时重试？
我根据自己的项目经验，把常见场景分了这么几类：
- 网络抖动：别把它当个例，它就是常态。你在A可用区调B可用区的SDK，丢包率0.1%已经算不错的了。重试1次就能挡掉大部分偶发超时。
- 后端服务短暂重启：比如你在做灰度发布，老实例下线、新实例拉起来，中间有几十毫秒的空档。你碰巧赶上，重试一次就好了。
- 数据库连接池耗尽：这个我踩过很深的坑。有一次数据库连接池瞬间撑满，我们查询SDK的超时时间设了30秒。30秒内所有调用都在等，最后整条链路全挂。解决方案：把超时时间缩短到1秒，加上最多2次重试，配合快速失败。
- 分布式系统节点故障：比如Consul注册中心里某个节点掉线了，你恰好命中它。重试换一个节点就好了。
- 上游限流：对方抛了429 Too Many Requests。这时候不是无脑重试，而是要带退避。我习惯的做法是看响应头里的Retry-After，没有的话就走指数退避。
避坑指南｜千万不要这样重试
我曾经见过一个团队，把重试间隔写死了100毫秒，重试次数设成10次。你算算，1秒内发出去10次调用。下游只要稍微有点压力，这几千个实例一拥而上，直接把对端打挂了。这不是重试，是DDoS攻击。
正确的做法是：有限次重试 + 指数退避 + 随机抖动。
再比如，有些SDK本身就已经封装了重试逻辑，比如gRPC、Spring Retry。你再去包一层重试，反而会叠加。我建议：先搞清楚SDK本身有没有重试，有的话只配参数；没有的话再自己封装。
好了，咱们先铺垫这么多。超时重试不是玄学，它是有公式、有策略、有边界的工程决策。下面这张图，帮你梳理了本章的知识结构：
图中你可以看到，整个体系从概念出发，连接到超时类型（连接超时和读取超时），再到常见场景和处理策略，最后落到避坑指南。别忘了右侧的“核心原则”框——有限重试和指数退避，这两条请刻在脑子里。
嗯，今天就先到这里。记住一句话：超时是必然的，重试是必要的，但无脑重试是致命的。后面我会带着你一步一步搭建起一套可用的重试框架，咱们不玩虚的。