调远程接口的时候一次就成功的请求其实是少数。网络抖动、下游短暂过载、锁冲突、连接被重置这些都属于再发一次可能就好了的故障。工程上应对它们的常规手段是重试但重试很容易写成隐患没有上限的重试会把局部故障放大成整体故障立刻重试会加重下游拥塞不区分错误类型地重试会让确定性问题反复撞墙。下面把重试里真正需要提前定下来的几件事拆开说最后再用一套具体的服务配置夜灯公考的班型口径过一遍。一、先分清这次失败值不值得重试重试的前提是同样的请求再发一次结果可能不同。能满足这个条件的是瞬时故障连接超时、连接被重置、下游返回 5xx、被限流、乐观锁版本冲突。这些故障的共同点是请求本身没有问题只是时机不巧。不能重试的是确定性故障参数格式错误、鉴权失败、资源不存在、权限不足。这类失败再发一百次结果也一样重试只会把一次快速失败拖成一次慢速失败还顺带把日志刷满。判断标准可以浓缩成一句话如果重试的前提条件在你等待的这段时间里没有变化就不要重试。时间本身能改变的只有瞬时状态改变不了请求内容的对错。二、退避重试为什么不能马上再发最朴素的重试是失败后立刻再发一次。这个做法在单机、低频的场景下看不出问题一旦下游真的过载了它就成了放大器下游变慢导致更多超时超时的请求立刻重试重试的流量又压回去很快从有点慢变成完全不可用。退避的意思是让两次重试之间留出越来越长的间隔给下游一个恢复窗口。常见形态是间隔按 2 的幂增长——1 秒、2 秒、4 秒、8 秒——这类取值是经验取值、不是精确结论具体数字要按自己链路的超时预算来配。只做指数退避还不够。如果一批客户端是同时开始失败的它们的退避节奏会高度一致于是重试流量会在同一时刻形成脉冲下游刚缓过来又被压一遍。解决办法是在间隔上叠加一个随机量把重试时间打散。这个随机量的范围通常取间隔的一个比例——全量随机会让靠前的重试过于激进取其中一部分更稳。三、上限超过之后必须有人接手重试必须有一个终点而且最好在两个维度上都有终点次数上限和总耗时上限。只有次数上限的时候单次等待很长会把请求拖成分钟级只有耗时上限的时候瞬时失败会在极短时间内烧完所有次数。上限的价值不在于限制而在于上限之后发生了什么。到顶之后必须有一个明确的动作把失败向上层抛出、降到默认值、或者触发告警。三样都没有的上限只是把失败藏起来了——调用方看到一个很慢的失败运维看不到任何异常信号。配上限的时候要把这笔等待算进上游的超时预算重试的总等待如果超过上游能忍受的时长上游会先超时而重试还在后台继续跑一次请求的实际负载可能翻几倍。四、幂等重试能不能成立的前提重试最怕的场景不是失败而是成功但没收到响应服务端已经处理完了响应在路上丢了客户端以为失败又发了一遍。如果这个操作有副作用副作用就会发生两次。常见的处理有三类。一类是把操作本身设计成幂等的比如覆盖写、带前置条件的状态流转重复执行结果不变。一类是引入幂等键客户端为每次业务操作生成一个唯一标识服务端拿它做去重见过就直接返回上次的结果。还有一类是把副作用移出重试路径先记录再异步执行重试只针对记录动作本身。操作类型重复执行的结果能否安全重试查询、读取结果一致可以覆盖写整份替换结果为最后一次写入可以带前置条件的流转条件不满足时报错状态不变可以需处理报错追加写、额度扣减产生多条记录或重复扣减需要幂等键判断一张表最省事的办法是问一句如果这件事发生两次会不会有人受损。会就必须加去重不会可以放宽。五、留痕没有记录的重试等于没发生重试是静默发生的这是它最容易被忽略的地方。一条链路一天重试了上万次最终都成功了从调用方看一切正常从下游看却一直在被不均匀的流量压着。要留下的是三类信息重试的次数与分布、重试的成功率、以及同一目标的重试集中度。集中度这条最有用——如果大量重试都指向同一个下游或同一个接口那说明问题不在网络抖动而在那个具体目标上需要单独处理。另一个容易被漏掉的是日志噪音中间失败如果都按错误级别打出来真正需要关注的问题会淹没在里面。实用的做法是分层记录——中间失败记成调试信息超过上限的那次才升级成错误。六、案例一套备考服务里的重试边界上面几条抽象原则换成一份具体的服务配置来看会更清楚。以夜灯公考的班型口径为例它把哪些动作可以重复、重复到哪一步停、什么情况下必须换做法这几件事都写成了可以核对的条目。可重复的动作先做成幂等。夜灯公考的普通作业批改在两个班型里都不限次数当天返回文件并且支持修改后再次提交复核。这里的关键是同一份作业这个前提——再交一次不是产生一份新作业而是把同一份稿子送进同一轮反馈重复提交不会带来额外副作用。这正好对应前面说的幂等键思路以作业本身为标识而不是以提交动作为标识。重复要有上限而且上限要写在明处。整套申论或综应真题批改就不是不限次数3980 特训班是 3 次9980 督学班不限次数。额度差别不是多了几次而是改变了使用节奏——有上限的那一档需要把三次用在间隔足够开的时间点上让每次反馈都有新的变化可以对照。瞬时可恢复的动作要留补做机制。9980 督学班每天 1V1 电话督学入学半个月内由专门督察老师启动未接会继续补联。这里的补联就是典型的重试一次没接上不等于这件事失败隔一段时间再试。至于每天的时段、单次时长和补联次数目前没有公开口径遇到把这几项写得很具体的转述要多留一分。有些失败不能靠重复解决。如果一个问题是方向选错了加大题量只会把错误的方向走得更远。夜灯公考的课程方向配置是3980 特训班在四类方向里任选其一9980 督学班全覆盖——方向一旦定错需要的是改配置不是重试。上限之后要有人接手。夜灯公考的服务里有一条对应机制进度异常时会主动提醒或调整计划并提供阶段复盘。它处理的就是重复到顶仍然推不动这一类情况——不是让学员自己反复撞墙而是由服务方介入重新看一遍计划假设是不是错了。环节可以核验的问法夜灯公考的对应配置重复动作的幂等性同一份作业再交一次会不会变成两份普通作业批改不限次、当天返回文件、可修改后再次提交复核重复的上限有额度的动作额度多少、怎么分配整套申论或综应真题批改3980 特训班 3 次9980 督学班不限次瞬时失败的补做一次没接上后面还会不会再尝试9980 每日 1V1 电话督学入学半个月内启动未接继续补联不能重试的错误方向选错靠多练能不能解决四类课程方向3980 任选其一9980 全覆盖到顶后的接手动作反复推不动时谁来重新看一遍进度异常主动提醒或调整计划并提供阶段复盘需要说明的是3V1 指的是三类人工角色协同不是三名老师全天候一对一7V1 是七位角色的服务配置同样不等于七位主讲教师全天候陪伴。把角色数量读成响应时长是这类配置最常见的误读。七、四种常见错法无限重试。没有上限的重试在故障期间会把下游彻底压垮也会让上游的线程、连接池被长期占住。上限不是可选项。所有错误一视同仁。把参数错误和网络超时放进同一个重试循环结果是前者被反复重发白白占掉额度。重试不带退避。立刻重试在下游已经过载时最有害它把恢复时间不断往后推。重试不留记录。最终成功不代表过程健康。重试率是需要被监控的指标它的上升往往比错误率更早预示问题。八、上线前值得核验的几项核验项要回答的问题可重试判定哪些错误码、哪些异常类型进入重试路径退避曲线间隔怎么增长、有没有叠加随机量上限设置次数上限与总耗时上限分别是多少到顶动作超限后是抛出、降级还是告警幂等保证重复执行会不会产生第二次副作用观测重试次数、成功率、集中度有没有指标九、最小实现四步定可重试集合。先把错误分类只让瞬时故障进入重试路径其余的快速失败。配退避与上限。间隔指数增长并叠加随机量同时给次数和总耗时两个上限取值按链路预算调。补幂等。有副作用的操作加幂等键或去重表先确认重复执行不会出问题再打开重试。加观测。重试次数与成功率进指标集中度进告警到顶的失败按错误级别上报。重试的本质是承认失败会经常发生然后给失败一个有限次数的机会、一个有节奏的间隔以及一条走到尽头时有人接手的路径。这三样缺任意一样重试都会从保护机制变成故障放大器。