07｜超时控制：怎么保证用户一定能在1s内拿到响应？
前置知识
超时控制目标
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了超时控制在构建高可用系统中的重要性及应用。文章详细介绍了超时控制的目标、形态、确定超时时间的方式以及超时中断业务等方面。特别强调了链路超时控制在微服务架构中的重要性。读者可以从中了解到超时控制的核心概念和实际应用方法，对于构建高可用系统具有重要参考价值。 文章首先强调了超时控制在构建高可用系统中的重要性，详细介绍了超时控制的目标，包括确保用户在预期时间内获得响应以及及时释放资源。文章还介绍了调用超时控制和链路超时控制两种形态，并强调了链路超时控制在微服务架构中的重要性。确定超时时间的方式包括根据用户体验、被调用接口的响应时间、压力测试和根据代码计算。此外，超时中断业务也是一个值得深入讨论的问题。 在具体讨论链路超时控制时，文章提到了传递超时时间的方式，以及如何处理服务提供者无法在规定时间内返回响应的情况。最后，文章提供了思考题，引导读者深入思考超时控制相关问题。 总的来说，本文对超时控制的重要性、实际应用方法以及相关问题进行了深入探讨，对于想要深入了解超时控制的读者来说，是一份极具价值的资料。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(14)
- 最新
- 精选
penbox1. 在根据被调用接口的响应时间来确定超时时间里面，提到可以使用 99 线或 999 线来作为超时时间。那么平均响应时间和响应时间的中位数，能不能作为超时时间？ 不能，这意味着一半的请求都会超时，业务基本处于不可用的状态了。 2. 在监听超时那里，能不能只在服务端那边监听超时，而客户端完全不管？ 我觉得不行，客户端不能保证所有服务端都是做了超时控制的，也不能保证请求就一定就能到服务端那边。 假如发生了网络故障，服务端根本收不到请求，客户端本地没做超时控制的话，就会发生线程泄露。作者回复: 赞，回答得很对！
2023-07-04归属地：四川6
IT小村上下游反了吧作者回复: 没有，我用的不是老外思维中的 Down stream up stream 的说法，就是比较符合中文语境下的那种说法。如果你不习惯的话，你可以自动在脑海里面替换一下，问题也不大。
2023-11-05归属地：北京
傲娇的小宝关于问题一：我和马云一平均我也资产上e呢，中位数对于超时场景没有意义。而且既然是中，说明有一半达不到，那服务总不能只为剩下能达到的提供正确返回呐。 关于问题二：如果客户端不管，不太保险，因为是否超时就完全取决于服务端了，一方面可能与业务要求不符，另一方面可能引发一些无法判断的问题。作者回复: 赞。 问题二还涉及到一个问题，那就是即便服务端返回了超时响应，但是客户端也有可能收不到，因为网络通信总是不稳定的。又或者收到了超时的时候，已经过去了很久了，远大于超时时间。
2023-10-31归属地：北京- Geek_6806321.不能，这里需要考虑的是最差的情况；2.不行，客户端需要在超时展示相应的处理方案。
作者回复: 赞！ 2 主要是因为，服务端的超时响应，客户端可能完全收不到，比如说网络出现了问题。
2023-10-17归属地：浙江 
浩仔是程序员在调用第三方接口设置超时时间还应该考虑接口的qps，服务部署导致的网络因素等，如果qps很高，超时时间太长，就容易把自己系统的线程打爆作者回复: 是的，对于客户端来说，超时控制能够释放自己的资源；对于服务端来说，就要考虑限流之类的措施了。
2023-07-27归属地：广东
ZhiguoXue_IT现在的开发接口的时候，都给前端承诺当前接口的tp99，之前没实现过在服务端自己控制时长，也就是服务端是如何控制如果1s没有执行完就给客户端返回特殊的值？作者回复: 我这里用的都是服务 A 调用服务 B 的例子。如果你是浏览器那边过来，那么只能是浏览器那边设置超时。
2023-07-27归属地：北京
humor原则上是看公司的可用性要求，要求几个 9 就要几个 9。如果没有硬性规定，那么看 99 线和 999 线相差多不多。不多的话就用 999 线，多的话就用 99 线。 这里为什么99线和999线差的多的话用99线呢？如果两者差距比较大，不是应该选999线更好吗，这样超时报错会少很多作者回复: 如果相差很多话，有点不太值得选 999 线。我举个例子，比如说有些系统会有很明显的长尾请求。假设说 99 线可能是 1s，结果 999 线是 3s。正常来说这种时候我都不会考虑 999 线。
2023-07-14归属地：浙江2- Geek_18dfaf老师，在哪些微服务框架里面，服务端做了超时时间的监听
作者回复: 实际上，超时是在 RPC 协议上做的。如果 RPC 协议设计了超时字段，那么基本上服务端都会处理，比如说 gRPC 就做了
2023-07-11归属地：上海 
信客老师，针对“用户看到失败响应，但实际已经执行成功”这种现象 1. 感觉不论是客户端监听，还是客户端和服务端都监听（比如，服务端执行完了，但恰好在传输结果时，客户端发生超时，返回了失败响应），都可能发生这种现象？ 2. 站在用户的角度来说，很confusing，明明看到失败，但第二次说已经有人注册。这种情况一般要怎么处理呢？作者回复: 1. 你说得对，因为你做不到彻底中断业务。比如插入这个例子，你在等待 MySQL 返回响应，那么你肯定没办法让 MySQL 插入一半之后就不插入了 2. 并没有什么好的手段，你只能提示一下用户，然后让用户跳转登录。
2023-07-10归属地：北京2
peter请教老师几个问题： 本课有一个疑问： Q1：“释放资源”，服务端也有这个需要吧。 超时后释放资源，文中都是针对客户端讲的。服务端没有释放资源这个需求吗？ 下面是02课的问题，因为我阅读的晚，所以也发的晚，这里补上： Q1：“客户端”并不是指终端，对吗？ 本课中用到的“客户端”，我理解并不是通常意义上的网页或APP，而是相对于“服务端”的客户端；从后面的内容来看，也不是指Nginx或网关。那在微服务架构中，具体是指什么？ Q2：哈希算法怎么保证均匀吗？ 文中“所以要尽可能保证哈希值计算出来的结果是均匀的”，有什么具体方法来保证哈希的均匀性？ Q3：负载均衡有多种算法，对于一个公司来说，是确定用其中的某一种吗？或者是不同的子系统可能采用不同的算法？或者有多种算法，会根据情况动态选用其中的某一种？ Q4：“响应+元数据”这种，消息是怎么发送的？ 响应是给用户的，通常就是HTTP消息，元数据是内部用的，这两种怎么处理？定义一个内部消息，包含这两种，Nginx收到后取出元数据然后将响应发给用户吗？作者回复: 1. 有的，但是要少一点。比如说你服务端处理一个异步任务，然后发现执行超过了预期时间，你强制杀掉，也算是释放资源。 2. 如果 A 调用了 B，那么 A 就是 B 的客户端，B 就是 A 的服务端。一般我们说的客户端都不会指用户的那个终端，后面也是这样。 后面三个问题我都回过你了，只不过那时候我还不太熟练，所以用的不是作者身份回你。你可以回去看看。
2023-06-30归属地：北京
