武汉网站关键词高质量外链

😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本专栏《八股消消乐》旨在记录个人所背的八股文，包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点，期待与你一同探索、学习、进步，一起卷起来叭！

题目

💬技术栈：微服务架构

🔍简历内容：熟悉链路超时控制策略，有一定的实践经验。

🚩面试问：如果 A 调用 B，B 调用 C 的这条链路的超时时间设置为 1s，但是 B 这个服务的提供者就说自己是不可能在 1s 内返回响应的，那么该怎么办？

---

💡建议暂停思考10s，你有答案了嘛？如果你有不同题解，欢迎评论区留言、打卡。

---

答案

超时控制

目标

• 确保客户端能在预期的时间内拿到响应。用户体验一个重要理念“坏响应也比没响应好”。
  
• 及时释放资源。其中影响最大的是线程和连接两种资源。
  • 释放线程：在超时的情况下，客户端收到了超时响应之后就可以继续往后执行，等执行完毕，这个线程就可以被用于执行别的业务。而如果没有超时控制，那么这个线程就会被一直占有。而像Go这种语言，协程会被一直占有。
  • 释放连接：连接可以是 RPC 连接，也可以是数据库连接。类似的道理，如果没有拿到响应，客户端会一直占据这个连接。

形态

超时控制从形态上来看分成两种：

• 调用超时控制，比如说你在调用下游接口的时候，为这一次调用设置一个超时时间。
• 链路超时控制，是指整条调用链路被一个超时时间控制。比如说你的业务有一条链路是 A 调用 B，B 调用 C。如果链路超时时间是 1s，首先 A 调用 B 的超时时间是 1s，如果 B 收到请求的时候已经过去了 200ms，那么 B 调用 C 的超时时间就不能超过 800ms。

大厂的 App 首页接口响应时间都有硬性规定：例如某司的要求是 50ms，也就是说不管你后端多复杂，不管你后面调用多少个服务，你的响应时间都必须控制在 50ms 以内。

确定超时

超时时间要设置合理，过长可能会因为资源释放不及时而出事故，过短可能调用者会频繁超时，业务几乎没有办法执行。

（1）根据用户体验来确定 => 征求产品经历的意见。

（2）根据被调用接口的响应时间来确定 => 一般情况下，你可以选择使用 99 线 或者 999 线 来作为超时时间。【所谓的 99 线是指 99% 的请求，响应时间都在这个值以内。比如说 99 线为 1s，那么意味着 99% 的请求响应时间都在 1s 以内。999 线也是类似的含义。】

这种方式要求这个接口已经接入了类似 Prometheus 之类的可观测性工具，能够算出 99 线或者 999 线。如果一个接口是新接口，你要调用它，而这时候根本没有 99 线或者 999 线的数据。那么你可以考虑使用压力测试。

（3）根据压测结果来确定

很多公司其实内部没有什么压测环境，也不可能让你停下新功能开发去做压力测试。那么就无法采用压力测试来采集到响应时间数据。

（4）根据代码来确定

超时中断业务

当调用一个服务超时之后，这个服务基本上会继续执行，除非服务端自己主动检测一下本次收到的请求是否已经超时了。

如果你的业务逻辑有 A、B、C 三个步骤。假如说你执行到 B 的时候超时了，如果你的代码里面没有检测到，那么还是会继续执行 C。但是如果你 主动 检测了超时，那么你就可以在 B 执行之后就返回。但是正常在实践中，我们是不会写这种手动检测的繁琐代码的。所以经常出现一个问题，就是客户端虽然超时了，但是实际上服务端已经执行成功了。

监听超时时间

简历准备

信息收集：

• 你所在公司的核心业务，尤其是App首页之类的，公司层面上的性能要求是什么？也就是说响应时间必须控制在多少以内，然后进一步了解有没有采用链路超时控制。
• 你自己维护的服务调用下游的时候有没有设置超时时间，超时时间都是多长？
• 数据库查询有没有设置超时时间？
• 跟任何第三方中间件打交道的代码有没有设置超时时间？例如查询 Redis，发送消息到 Kafka等。
• 收集一些跟超时控制相关的事故报告。例如因为没有设置超时时间，导致数据库连接耗尽或者线程数量飙升等事故报告。

你在调用别的服务的时候有没有设置超时时间？

超时控制目标：我会设置超时时间，一般来说设置超时时间是为了用户体验和及时释放资源。比如说我有一个接口是提供给首页使用的，整个接口要求的超时时间是不超过 100ms。这个 100ms 就是公司规定的，是从用户体验出发确定的超时时间。

如果公司没这种规定你怎么确定合理的超时时间呢？

四种手段：

• 咨询一下产品经理，从用户体验的角度出发确定超时时间。
• 根据被调用接口的响应时间，来确定调用者的超时时间。
• 要调用的是一个新接口，没有性能数据，那么就可以考虑执行压测，然后根据结果选用 99 线或者 999 线。
• 根据代码里面的复杂操作来计算一个时间。

99 线和 999 线究竟选哪个比较好?

原则上是看公司的可用性要求，要求几个 9 就要几个 9。如果没有硬性规定，那么看 99 线和 999 线相差多不多。不多的话就用 999 线，多的话就用 99 线。

补充一个因为超时控制设置不合理而出现的事故。

正常来说，对任何第三方的调用我都会设置超时时间。如果没有设置超时时间或者超时时间过长，都可能引起资源泄露。比如说早期我们公司就出现过一个事故，某个同事的数据库查询超时时间设置得过长，在数据库性能出现抖动的时候，客户端的所有查询都被长时间阻塞，导致连接池中的连接耗尽。

链路超时控制

链路超时控制会作用于整条链路上的任何一环。例如在 A 调用 B，B 调用 C 的链路中，如果 A 设置了超时时间 1s，那么 A 调用 B 不能超过 1s。然后当 B 收到请求之后，如果已经过去了 200ms，那么 B 调用 C 的超时时间就不能超过 800ms。

核心：在链路中传递超时时间。

（1）协议头：

正常来说，在链路中传递的可以是 剩余超时时间，也可以是 超时时间戳。

传递剩余超时时间：服务端收到请求之后，要减去请求在网络中传输的时间。不过现实中很难计算网络传输花的时间。（性能测试，要完全模拟线上环境，否则计算就会有偏差。）
传递超时时间戳：容易受到时钟同步影响。假如说此时此刻，A 的时钟是 00:00:00，而 B 的时钟是 00:00:01，也就是 A 的时钟比 B 的时钟慢了一秒。那么如果 A 传递的超时时间戳是 00:00:01，那么 B 一收到请求，就会认为这个请求已经超时了。正常来说时钟同步不至于出现那么大的偏差，大多数时钟偏差几乎可以忽略不计。

如果 A 调用 B，B 调用 C 的这条链路的超时时间设置为 1s，但是 B 这个服务的提供者就说自己是不可能在 1s 内返回响应的，那么该怎么办？
可以考虑请 B 的维护者喝杯奶茶，吃顿小烧烤，然后要求 B 优化性能。

---

往期精彩专栏内容，欢迎订阅：

🔗【八股消消乐】20250614：构建微服务架构体系—实现制作库与线上库分离
🔗【八股消消乐】20250612：构建微服务架构体系—限流算法优化
🔗【八股消消乐】20250611：构建微服务架构体系—降级策略全总结
🔗【八股消消乐】20250610：构建微服务架构体系—熔断恢复抖动优化
🔗【八股消消乐】20250609：构建微服务架构体系—负载均衡算法如何优化
🔗【八股消消乐】20250608：构建微服务架构体系—服务注册与发现
🔗【八股消消乐】20250607：MySQL存储引擎InnoDB知识点汇总
🔗【八股消消乐】20250606：MySQL参数优化大汇总
🔗【八股消消乐】20250605：端午节产生的消费数据，如何分表分库？
🔗【八股消消乐】20250604：如何解决SQL线上死锁事故
🔗【八股消消乐】20250603：索引失效与优化方法总结
🔗【八股消消乐】20250512：慢SQL优化手段总结
🔗【八股消消乐】20250511：项目中如何排查内存持续上升问题
🔗【八股消消乐】20250510：项目中如何优化JVM内存分配？
🔗【八股消消乐】20250509：你在项目中如何优化垃圾回收机制？
🔗【八股消消乐】20250508：Java编译优化技术在项目中的应用
🔗【八股消消乐】20250507：你了解JVM内存模型吗？
🔗【八股消消乐】20250506：你是如何设置线程池大小？
🔗【八股消消乐】20250430：十分钟带背Duubo中大厂经典面试题
🔗【八股消消乐】20250429：你是如何在项目场景中选取最优并发容器？
🔗【八股消消乐】20250428：你是项目中如何优化多线程上下文切换？
🔗【八股消消乐】20250427：发送请求有遇到服务不可用吗？如何解决？

📌 [ 笔者 ]   文艺倾年
📃 [ 更新 ]   2025.6.15
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限，本文有错误和不准确之处在所难免，本人也很想知道这些错误，恳望读者批评指正！