云服务器请求超时如何优化?

去年秋天，一个做在线考试平台的朋友大刘请我吃饭，饭桌上却一直心不在焉，不停看手机。我以为他家里有什么事，一问才知道，他们平台当天下午有一场全省统一的模拟考试，几万名学生同时在线答题。结果考试开始后不到十分钟，系统就开始卡顿，提交答案的按钮点下去之后要转很久很久的圈，有些学生甚至直接收到了请求超时的提示。大刘说他们的云服务器配置不算低，但一到这种高并发场景就撑不住，他问我到底应该怎么优化才能避免请求超时。

我跟大刘说，请求超时这个问题，表面上看是服务器响应慢了，但实际上原因可能出在整个链条的任何一个环节。有的超时是客户端等不及了主动断开，有的是服务器处理不过来把你晾在那儿了，有的是网络中间某个节点把你的包给丢了。想要优化，得先把超时发生在哪个环节搞清楚，然后对症下药。

大刘遇到的这种高并发下的超时问题，其实特别典型。今天我就结合自己处理过的各种超时案例，把云服务器请求超时的优化思路从浅到深地讲一讲。

我们先从最基础的层面说起，就是客户端和服务器之间的网络链路。你的一台云服务器在某个机房，用户在地球的某个角落，中间可能经过几十个路由器和交换机。任何一个节点出了问题，比如某个路由器丢包率突然升高，或者某条国际出口线路拥堵，都可能导致数据包传输变慢，最终触发超时。怎么判断是不是网络链路的问题呢，一个比较简单的办法是在用户端做路由追踪，看看每一跳的延迟情况。如果发现某一个中间节点的延迟特别高或者出现了丢包，那问题就不在你这边。这种情况你能做的事情不多，一般只能等网络自己恢复，或者考虑换一个网络线路质量更好的云服务器机房。

接下来是域名解析环节的超时。如果你的应用是通过域名来访问云服务器的，那么每次请求之前都会先做一次域名解析。如果解析服务的响应慢，或者你配置的DNS服务器不稳定，这个解析过程就可能消耗几百毫秒甚至几秒钟。在用户看来，就是点击之后等了很久才开始加载。优化这个环节的方法有两个，一是在你的应用里使用更稳定的DNS服务商，二是尽量复用已经解析出来的IP地址，不要每次请求都重新解析。

大刘他们用的是云服务商提供的负载均衡服务，负载均衡器前面还挂了一个CDN。我让他们先看看CDN的命中率和回源延迟。结果发现，当天下午的考试中，大量的请求是动态接口的请求，CDN对这些动态请求几乎不起作用，每次都需要回源到云服务器。而云服务器只有一台，几万个学生的请求全部打到了这一台机器上，这就是超时的根源。

这就引出了第二个层面，服务器自身的处理能力。当请求到达你的云服务器之后，服务器需要分配一个工作进程或者线程来处理这个请求。如果你的服务器同时能处理的最大并发数是五百个，这时候来了五千个请求，那多出来的四千五百个请求就要排队等待。每个请求在队列里等的时间越长，超时的可能性就越大。解决这个问题最直接的办法就是提升服务器的处理能力，要么升级云服务器的配置，多给几个CPU核心和更多的内存，要么增加服务器的数量，在前面加一个负载均衡器，把请求分散到多台机器上去处理。

大刘后来就是采用了后面这个方案，他们把应用部署到了三台云服务器上，前面用一个负载均衡器来分发请求。三台机器同时处理，单台机器的压力降到了原来的三分之一，超时的问题立刻得到了缓解。但过了没多久，新的问题又出现了。

第三个层面是应用程序本身的效率问题。有时候服务器配置很高，数量也不少，但请求还是超时，问题就出在代码上了。你的代码执行太慢，一个请求处理了一秒钟，在并发量低的时候没什么感觉，但并发量一高，所有请求都处理得慢，服务器里面的请求队列就会迅速堆积。常见的慢代码问题有这么几种。一是循环里执行了数据库查询，每循环一次查一次数据库，循环一百次就是一百次查询。二是没有使用缓存，相同的数据每次都要重新计算或者重新查询。三是在请求路径上做了太多的日志记录，大量的字符串拼接和磁盘写入拖慢了整个流程。四是使用了同步阻塞的调用方式，比如调用一个外部API，对方响应慢，你的线程就一直卡在那里等。

优化这类问题的方法，我总结了一个三步走的思路。第一步，先找到慢的地方，在你的代码里加上详细的耗时统计，看看到底是哪一行代码或者哪一个调用花的时间最多。第二步，针对最慢的那个点做优化，是循环查数据库的就改成批量查询，是没有缓存的就加上缓存，是日志太多的就减少不必要的日志。第三步，优化完成之后再次测量，确认效果。这个过程可能需要反复多次，把最慢的几个点逐个击破。

我处理过一个案例，一家做物流跟踪的公司，他们的查询接口经常超时。我去看他们的代码，发现每次查询物流轨迹的时候，会先查询订单表，然后根据订单里的物流单号去调用快递公司的API，拿到轨迹之后再更新到数据库里，然后返回给前端。这个流程本身没问题，但他们的代码里有一个细节，就是在循环里对同一个快递公司的API做了多次调用，因为一个订单可能有多个包裹。我建议他们把代码改成并行调用，同时去查询多个包裹的轨迹，总耗时从原来的串行累加变成了最慢的那个包裹的耗时，响应时间从三秒钟降到了八百毫秒。

第四个层面是数据库的瓶颈。很多请求超时的问题，根源不在应用代码本身，而在数据库。你的应用代码跑得飞快，但每次查询数据库都要等很久，请求就会被卡在数据库这一层。数据库慢的原因也有很多，比如数据表缺少索引，每次查询都要扫描几十万条数据。比如锁竞争严重，多个事务互相等待对方释放锁。比如数据库服务器的配置太低，内存不够用，频繁地从磁盘读取数据。比如SQL语句写得不好，关联了太多的表或者用了不适合的查询方式。

优化数据库层面的超时，我一般会从这几个方面入手。先开启数据库的慢查询日志，看看哪些查询执行时间最长。针对这些慢查询，分析它们的执行计划，看看有没有用上索引，没有的话就加索引。如果加了索引还是慢，就要考虑改写SQL语句，或者把复杂的关联查询拆分成多个简单的查询，在应用层做数据的组装。还有一种情况是数据库的连接数设置得太小，大量请求在等待获取连接，这时候可以适当调大连接数，但要注意不能调得太大，否则数据库本身会被压垮。

大刘他们优化完应用代码之后，发现还有一个超时发生在考试结束后的成绩汇总环节。这个汇总需要读取所有学生的答题记录，计算分数和排名。这个查询涉及到的数据量非常大，每次执行都要花将近十秒钟。他们原来的做法是在用户点击查看成绩的时候实时计算，这显然不合理。我建议他们改成异步的方式，考试结束后在后台跑一个定时任务来计算成绩，算完之后存到结果表里，用户查看成绩的时候直接读取已经算好的结果，响应时间就从十秒钟变成了几十毫秒。

第五个层面是外部依赖的超时。你的云服务器在处理一个请求的时候，可能需要调用第三方的API，访问对象存储，或者连接消息队列。这些外部依赖如果响应慢了，你的请求也会跟着慢。解决这类问题的方法有几个。一是给所有外部依赖的调用设置合理的超时时间，不能让它无限期地等下去。二是对于非核心的依赖，可以考虑使用熔断机制，当某个依赖连续失败或者超时多次之后，暂时不再调用它，直接返回一个降级的结果。三是尽量使用异步的方式调用外部依赖，不要在主请求路径上同步等待。

有一次一个做社交应用的朋友找我，他们的用户评论接口经常超时。分析之后发现，每次用户发表评论的时候，代码里会同步调用一个敏感词过滤的API。这个API有时候响应很慢，用户发一条评论要等两三秒钟。我建议他们把敏感词过滤改成异步的方式，用户发表评论的时候先写进数据库，标记为待审核，后台再慢慢去过滤。这样用户发完评论立刻就能看到自己的评论显示出来了，虽然实际过滤是在后面做的，但用户的体验好了很多，超时的问题也消失了。

第六个层面是请求链路过长。一个请求从用户端到云服务器，中间可能经过了CDN、负载均衡器、反向代理、Web应用防火墙、应用服务器、缓存服务、数据库服务。每一层都会增加一点延迟，所有的延迟加起来就是一个不小的数字。当你的请求本身处理时间只有五十毫秒，但中间层层加码之后总延迟变成了一百五十毫秒，在用户看来就是慢了。优化这个环节的方法是审视你的架构，去掉不必要的中间层，或者把多个功能合并到同一台机器上处理，减少网络跳转。

还有一个容易被忽视的点是慢客户端。有时候不是你的服务器慢，而是用户那边的网络慢或者设备性能差。比如用户用的是2G网络，上传一个较大的请求体要花很长时间，服务器一直在等待接收数据，最终触发了超时。这种情况你没法优化用户的设备和网络，但可以在你的代码里做一些适配，比如压缩请求体的体积，或者对大文件采用分片上传的方式。

大刘的考试平台经过这几个层面的优化之后，后面又搞了几次大规模的模拟考试，没有再出现过请求超时的问题。但大刘跟我说，他最大的收获不是学了一堆技术优化的技巧，而是明白了优化这件事不能等到出问题了再做，应该从一开始就考虑进去。他现在每次上线新功能之前，都会先用压测工具模拟高并发场景，看看哪些接口会超时，提前做好优化。

总结一下，云服务器请求超时的优化可以从这几个方向入手。先从网络链路开始检查，看看是不是公网路由或者DNS解析导致的延迟。然后看服务器的处理能力，CPU、内存、并发连接数是不是达到了瓶颈。接着审视你的应用代码，找出那些执行慢的逻辑，用缓存、批量处理、并行调用等手段来优化。再检查数据库，加索引、改SQL、调优配置、做读写分离。对外部依赖要设置合理的超时和熔断机制，避免被慢服务拖垮。审视整个请求链路，去掉不必要的中间环节。最后别忘了慢客户端的问题，适当压缩数据或者改用异步上传。

请求超时不是一天形成的，往往是多个小问题叠加在一起，在流量高峰的时候被放大了。优化也不是一个一次性的事情，而是一个持续的过程。每一次你发现了一个超时的问题，就追根溯源找到根本原因，然后把它修好。慢慢地，你的系统会变得越来越健壮，用户在那些关键时刻也就不会再看到转不完的圈圈了。