日期：2026-07-11
标签：#面试 #八股 #后端 #微服务 #RPC #场景题
一句话答案
没有通用固定值；应从调用方端到端 SLO 倒推，结合下游延迟分位数、网络抖动、业务重要性和重试次数设置，并持续基于监控调整。
面试口语版
我不会直接回答 3 秒或 5 秒。先确定上游接口的总超时预算，例如 800ms，再扣除网关、应用计算、序列化和返回网络时间，把剩余预算分配给下游调用。单次 RPC 超时应参考下游正常流量的 P99 或更高分位，再留少量网络抖动余量，但必须小于上游剩余 Deadline。读超时、连接超时和连接池获取超时要分开设置。若允许重试，单次超时乘以尝试次数再加退避时间不能超过总预算。
关键细节
- 超时过短会误杀正常请求并诱发重试；过长会占满线程、连接和内存，扩大故障。
- 调用方应传递绝对 Deadline 或剩余预算，下游不能每一跳重新获得完整超时。
- 只对幂等、瞬态错误做有限重试，并配合指数退避、随机抖动和重试预算。
- 批处理、查询和支付等业务的超时目标不同，应按方法配置而不是全局一个值。
面试官追问
- 为什么不能直接用 P99 作为超时？
- 连接超时和读取超时有什么区别？
- 超时后服务端还会继续执行吗？
- 如何动态调整超时时间？
面试官追问参考答案
1. 为什么不能直接用 P99 作为超时？
如果超时正好等于 P99，正常基线下就会有约 1% 请求超时，并可能因重试增加负载；P99 还会随流量、实例和窗口波动。应根据可接受误超时率选择更高分位或加合理余量，同时受上游总 Deadline 限制。
2. 连接超时和读取超时有什么区别？
连接超时限制 DNS/TCP/TLS 或连接建立阶段，读取超时限制连接成功后等待响应数据的时间；连接池获取超时又限制等待可用连接。三者应分别设置，才能区分网络不可达、池耗尽和服务处理慢。
3. 超时后服务端还会继续执行吗？
经常会。客户端放弃等待不代表服务端自动停止，除非协议传播取消且服务端、线程池和数据库操作都响应取消。因此写操作必须幂等，服务端检查 Deadline，并尽可能取消尚未开始或可中断的工作。
4. 如何动态调整超时时间？
持续统计不同方法、区域和下游的延迟分布，以 SLO 和误超时率为边界生成建议值，通过配置中心灰度下发。调整需设最小/最大值、变化速率和回滚，不能让故障期延迟升高自动无限放宽超时。
学习清单
- 能用一个具体 SLO 示例分配超时预算。
- 理解 Deadline 传播和重试预算。
维护与整理 · Yihui在 GitHub 上编辑