网站建设的销售术语,建模培训,白银市住房与建设局网站,搭建什么平台如何表达#x1f60a;你好#xff0c;我是小航#xff0c;一个正在变秃、变强的文艺倾年。 #x1f514;本专栏《八股消消乐》旨在记录个人所背的八股文#xff0c;包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点#xff… 你好我是小航一个正在变秃、变强的文艺倾年。 本专栏《八股消消乐》旨在记录个人所背的八股文包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点期待与你一同探索、学习、进步一起卷起来叭 目录 题目答案超时控制目标形态确定超时超时中断业务监听超时时间 简历准备链路超时控制 题目
技术栈微服务架构
简历内容熟悉链路超时控制策略有一定的实践经验。
面试问如果 A 调用 BB 调用 C 的这条链路的超时时间设置为 1s但是 B 这个服务的提供者就说自己是不可能在 1s 内返回响应的那么该怎么办 建议暂停思考10s你有答案了嘛如果你有不同题解欢迎评论区留言、打卡。 答案
超时控制
目标
确保客户端能在预期的时间内拿到响应。用户体验一个重要理念“坏响应也比没响应好”。 及时释放资源。其中影响最大的是线程和连接两种资源。 释放线程在超时的情况下客户端收到了超时响应之后就可以继续往后执行等执行完毕这个线程就可以被用于执行别的业务。而如果没有超时控制那么这个线程就会被一直占有。而像Go这种语言协程会被一直占有。释放连接连接可以是 RPC 连接也可以是数据库连接。类似的道理如果没有拿到响应客户端会一直占据这个连接。
形态
超时控制从形态上来看分成两种
调用超时控制比如说你在调用下游接口的时候为这一次调用设置一个超时时间。链路超时控制是指整条调用链路被一个超时时间控制。比如说你的业务有一条链路是 A 调用 BB 调用 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 调用 BB 调用 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 调用 BB 调用 C 的这条链路的超时时间设置为 1s但是 B 这个服务的提供者就说自己是不可能在 1s 内返回响应的那么该怎么办 可以考虑请 B 的维护者喝杯奶茶吃顿小烧烤然后要求 B 优化性能。 往期精彩专栏内容欢迎订阅
【八股消消乐】20250614构建微服务架构体系—实现制作库与线上库分离 【八股消消乐】20250612构建微服务架构体系—限流算法优化 【八股消消乐】20250611构建微服务架构体系—降级策略全总结 【八股消消乐】20250610构建微服务架构体系—熔断恢复抖动优化 【八股消消乐】20250609构建微服务架构体系—负载均衡算法如何优化 【八股消消乐】20250608构建微服务架构体系—服务注册与发现 【八股消消乐】20250607MySQL存储引擎InnoDB知识点汇总 【八股消消乐】20250606MySQL参数优化大汇总 【八股消消乐】20250605端午节产生的消费数据如何分表分库 【八股消消乐】20250604如何解决SQL线上死锁事故 【八股消消乐】20250603索引失效与优化方法总结 【八股消消乐】20250512慢SQL优化手段总结 【八股消消乐】20250511项目中如何排查内存持续上升问题 【八股消消乐】20250510项目中如何优化JVM内存分配 【八股消消乐】20250509你在项目中如何优化垃圾回收机制 【八股消消乐】20250508Java编译优化技术在项目中的应用 【八股消消乐】20250507你了解JVM内存模型吗 【八股消消乐】20250506你是如何设置线程池大小 【八股消消乐】20250430十分钟带背Duubo中大厂经典面试题 【八股消消乐】20250429你是如何在项目场景中选取最优并发容器 【八股消消乐】20250428你是项目中如何优化多线程上下文切换 【八股消消乐】20250427发送请求有遇到服务不可用吗如何解决 [ 笔者 ] 文艺倾年[ 更新 ] 2025.6.15
❌ [ 勘误 ] /* 暂无 */[ 声明 ] 由于作者水平有限本文有错误和不准确之处在所难免本人也很想知道这些错误恳望读者批评指正
