分布式调用中超时和重试应该如何设计？
简化版
超时用于避免调用方无限等待，重试用于应对短暂失败。设计时要给整条链路设置总耗时预算，再把预算分配给各个下游调用；重试只能用于幂等或可安全重复的操作，要限制次数，使用指数退避和随机抖动，避免重试风暴。超时太长会占满资源，太短会误伤正常请求；重试太多会放大下游故障。
详细版
超时要分层设置，包括连接超时、读超时、写超时、RPC 超时、业务总超时。上游超时时间应该大于下游单次超时加重试耗时，但不能超过用户可接受时间。链路越长，越需要 deadline 传递，避免每一层都重新给很长超时。
重试适合网络抖动、连接重置、临时 5xx 等短暂问题，不适合参数错误、权限错误、库存不足等确定性失败。重试必须配合幂等键、请求去重或业务幂等设计。工程上常用最大重试次数、指数退避、随机抖动、熔断和限流一起控制风险。
面试重点是：超时是保护资源，重试是提高成功率，但重试会放大流量，必须谨慎。
完整版教学
一、为什么超时很重要
在分布式系统里，一次请求可能跨越网关、业务服务、缓存、数据库、第三方接口等多个环节。任何一个环节变慢，如果调用方没有超时，就会一直等待。等待期间线程、连接、内存和队列都被占住，最终导致调用方也变慢。
超时的意义是给等待设置上限，让失败尽快暴露并释放资源。它不是消极放弃，而是稳定性边界。没有超时的系统，在下游慢故障面前非常脆弱。
二、超时应该如何分层
超时不是一个参数。连接超时控制建立连接的时间，读超时控制等待响应数据的时间，写超时控制发送请求的时间，RPC 超时控制一次远程调用总时间，业务超时控制整条请求链路总耗时。
设计时要从用户体验和服务 SLA 出发。比如页面接口要求 1 秒返回，就不能让某个下游单独等 900ms 再重试两次。更好的方式是设置全链路 deadline，每层拿到剩余时间后决定是否继续调用。这样可以避免链路层层叠加超时，导致请求早已没意义还在后台跑。
三、重试适合什么场景
重试解决的是短暂失败，比如网络闪断、连接池中某个连接坏掉、服务实例刚好重启、短暂 502。对于这类偶发问题，换一个实例或稍后再试，确实能提高成功率。
但重试不适合确定性失败。参数错误、权限不足、余额不足、库存不足，重试多少次都不会成功。也不适合下游已经过载的场景，因为重试会把流量放大，让下游雪上加霜。面试要明确：重试不是万能修复器，它是有副作用的可靠性手段。
四、如何避免重试风暴
重试风暴是指下游变慢或失败后，上游大量请求同时重试，导致流量成倍增加。比如原始 QPS 是 1000，每个请求重试 2 次，下游实际可能承受 3000 QPS。下游越慢，重试越多，形成恶性循环。
治理方式包括限制最大重试次数，使用指数退避，让下一次重试间隔逐步变长；加入随机抖动，避免大量请求同一时间重试；只对可恢复错误重试；配合熔断，当错误率过高时停止重试；配合限流，控制重试流量占比。
五、重试与幂等
只要请求可能被重复执行，就必须考虑幂等。查询请求通常天然幂等，重复查几次结果不变；创建订单、扣库存、扣款等写请求不天然幂等，重试可能导致重复创建或重复扣减。
工程上常用幂等键、唯一请求号、业务唯一索引、状态机流转、去重表等方式保证重复请求只生效一次。客户端超时后尤其危险，因为客户端不知道服务端是否已经处理成功。此时重试必须带同一个请求号，让服务端能识别重复。
六、面试追问与工程边界
常见追问是超时时间怎么定。答案是基于历史延迟分布、业务 SLA、链路预算和下游容量，而不是越大越安全。太大拖垮资源，太小误伤正常请求。可以从 P95/P99 延迟出发，再结合压测和错误率调整。
另一个追问是所有接口都要重试吗。不是。读接口、幂等写接口、短暂网络错误可以重试；非幂等写、明确业务失败、下游过载时不应盲目重试。重试策略要按错误码和业务语义区分。
七、落地设计清单
设计超时时，要先画出调用链路和耗时预算。比如用户接口整体 800ms 内返回，那么网关、业务服务、缓存、数据库、第三方接口每一段都要有预算，不能每层都设置 1 秒超时。RPC 框架最好支持 deadline 透传，让下游知道请求剩余时间；如果剩余时间不足，就应该直接失败或降级，而不是继续做无意义调用。
设计重试时，要建立错误分类。网络连接失败、连接被重置、短暂 502 可以重试；参数错误、权限错误、业务校验失败不应重试；超时是否重试要看接口是否幂等以及下游是否可能已经执行成功。每次重试都要带相同幂等键，尤其是创建订单、支付回调、发券、扣库存这类写操作。
八、常见误区和容量影响
第一个误区是把超时设置得很大，以为这样成功率更高。实际上超时过大会长期占用线程和连接，在下游慢故障时迅速拖垮调用方。第二个误区是多层都重试。网关重试、业务服务重试、RPC 客户端重试、消息消费再重试，叠加后可能从 1 次请求变成几十次下游调用。
容量评估时要把重试流量算进去。原始 1000 QPS，每次最多重试 2 次，理论峰值可能接近 3000 QPS。为了避免重试风暴，可以限制重试预算，给重试流量单独限流，使用指数退避和随机抖动，并在熔断打开后停止重试。重试策略本质上是成功率和系统压力之间的平衡。 还要区分同步重试和异步补偿。用户在线等待的链路里，重试次数应该很少，因为用户体验有明确时间上限；后台任务、消息消费、对账补偿可以使用更长周期的重试、死信队列和人工处理。把所有失败都放在同步链路里硬重试，会把用户请求拖慢，也会在高峰期放大压力。
九、常见误区与追问
这道题不能只背概念，要把「超时与重试」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 超时释放等待资源，重试对抗瞬时失败，但必须限制次数、退避并确保幂等 | 不要停在名词解释 |
| 流程机制 | 设置连接和读超时 -> 调用失败或超时 -> 判断错误是否可重试 -> 按退避重试 -> 超过次数失败 -> 业务幂等兜底 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 单次超时 200ms、重试 2 次，最坏调用耗时约 600ms，下游请求量最多放大 3 倍 | 治理组件是为了控制故障半径，不是让下游无限扛流量 |
超时与重试 面试拆解：
1. 设置连接和读超时
2. 调用失败或超时
3. 判断错误是否可重试
4. 按退避重试
5. 超过次数失败
6. 业务幂等兜底记忆钩子：先定位治理目标，再拆限流、熔断、降级、重试、追踪、灰度和幂等边界；回答时要紧扣「超时与重试」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：超时时间越长成功率越高。 过长会占用线程和连接，降低系统整体可用性。
- 误区：所有失败都应该重试。 参数错误、权限错误、非幂等写操作不应盲目重试。
- 误区：客户端超时说明服务端没执行。 服务端可能已执行成功，只是响应丢失或超时。
- 追问：重试风暴怎么避免？ 限制次数、指数退避、抖动、熔断和全链路重试预算。
- 追问：哪些操作适合重试？ 查询、幂等写、临时网络错误和可明确去重的请求。
- 追问：超时如何分层设置？ 上游总超时要大于下游单次但小于用户可接受时间，并留出重试预算。
十、加强记忆
超时是“别无限等”，重试是“短暂失败再试一次”。超时要有全链路预算和 deadline 传递；重试要限次数、退避、抖动、识别可重试错误，并且必须考虑幂等。重试能提升偶发成功率，也能放大故障，面试一定要讲它的副作用。