题目：服务器有多个节点，线上出现用户进入缓慢，监控服务器 CPU 和缓存没有什么压力，可以从哪些方面排查？
难度：high
标签：practice/business, practice/debug, architecture/design
评分：⭐⭐⭐⭐⭐（5/5）
从几个层面去排查,整个链路包括这么几个节点,用户->dns->服务网关->业务服务->缓存->数据库;我们可以从每个节点去对应进行排查;
首先如果是大规模的，那么基本上是服务端的问题。如果是个别反馈，那么可能是用户个人的问题。先从用户端开始查，这个就是看大量反馈还是少量的反馈。少量反馈先从用户端开始查。然后根据用户的 ID 信息查整个业务的调用链路，找到对应的链路追踪，比如 Skywalking。然后根据业务的用户的请求，找到对应的一个请求登录的地址。然后对应的去看整个调用链路的请求时长，是在业务侧整个链路某个节点出现了缓慢，还是说进入之后返回正常，只是用户侧感觉缓慢，这时候可能是用户的网络问题。
我们可以看一下用户和我们的网络所处环境，用户的 IP、用户的区域，对应是否有对应的区域服务器，是否存在网络比较高的延迟。我们可以，如果是 B 端的用户，我们可以找 B 端用户去对应的沟通，连接他们的网络，通过网络之间的转移，确认一下网络延迟是多少，从他们的网络到我们的服务，网络延迟是多少。
首先看一下他们在他们的位置 ping 一下我们的服务的域名，确认一下请求延迟是多少。如果延迟比较高，那是否确认是网络的问题。然后如果域名 ping 有问题，但是 ping IP 没有问题，那么是否是对应的 DNS 解析有问题？如果客户侧确认他们那没问题，而是链路中某个节点出现问题，比如业务健全或者是数据库缓存之类的存在问题，我们对应的再去排查处理对应的问题。
在整个链路节点上，看网关转发过程后，网关、DNS 到网关之间，网关转发的过程是否存在问题。因为看业务服务监控，CPU 跟缓存没有，内存没有压力，那么证明标准链路服务上是没什么问题的。然后看一下业务日志跟 Skywalking 日志，看具体是什么节点出现问题。如果是数据库层面的某些问题，去确认数据库是否出现其他操作导致数据库链接缓慢、链接被占之类的，或者是业务侧业务侧的链接、网络链接池之类的被占满。或者是服务器的有其他的开销，导致服务器的其他压力，使得用户访问服务器的时候，这个服务器存在问题。
基本上来说，就是从这几个对应的点去排查缓存，是否缓存出现丢失，然后大量的访问到数据库。但是或者是某一个请求的接口出现大范围的延迟，由于接口的阻塞导致整个业务链路的缓慢，这种也是有可能的。我当年碰见过某一个接口，因为有大量的查询。导致整个业务瘫痪，把所有数据库连接池打满了。噢，最终所有人都无法正常访问。这时候如果那个接口不是特别重要，或者是不影响主链路，可以先把接口临时下线掉，然后保证业务的正常运行。
优点：
不足：
补充：
ss -s）jstat -gc 看 GC 频率、Tomcat maxThreads 耗尽、连接池（HikariCP）耗尽ping、mtr、traceroute、iperf3、netstat -s 看 retransmitSHOW ENGINE INNODB STATUS）、连接数（max_connections）核心考点定位：考察"分布式链路排查"的完整方法论——从现象（缓慢）到根因（哪一层阻塞）的分层下钻。
知识点拆解：
ping/mtr/traceroute/iperf3/netstat -sjstat -gc、jmap -histo、Tomcat 工作线程数SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS考察方向：
延伸递进面试题：
SHOW PROCESSLIST 看连接来源、监控 active connections 指标、连接池参数（maxActive/maxWait）、慢查询治理（连接池耗尽通常是慢查询引起）【一句话结论】
面试官您好，"CPU 不高但 RT 高"是典型的"非 CPU 密集型瓶颈"，我按"用户端 → 网络 → 入口 → 应用 → 缓存 → 数据"六层排查，第一手证据是 Skywalking 链路追踪的 span 耗时分布。
【三点展开】
第一，先分规模：大规模反馈是服务端问题（配置错误、依赖故障、流量突增），个别反馈是用户端问题（网络、设备、地域）。用 Skywalking 查具体用户请求的 span 耗时，定位是哪个节点慢——是 DNS 解析慢、LB 转发慢、业务逻辑慢、还是数据库慢。
第二，按六层下钻：DNS 层用 dig 查解析时间和 TTL；网络层用 ping/mtr 查丢包和延迟，netstat -s 看 retransmit；入口层看 LB 连接数和会话保持；应用层用 jstat -gc 看 GC 频率，Tomcat maxThreads 是否耗尽；缓存层看 Redis SLOWLOG 和连接池；数据层看 SLOWLOG 和锁竞争。
第三，处置有优先级：先止血（熔断/限流/临时下线非核心接口），再定位（链路追踪 + 监控），最后根治（慢查询优化、连接池扩容、缓存预热）。我踩过一个坑：某接口大量查询打满数据库连接池，导致整个业务瘫痪——处置是临时下线该接口 + 加缓存 + 限流，事后复盘加连接池监控和慢查询告警。
【一句边界】
当然，如果是跨地域网络问题（用户在国内、服务在海外），那是 CDN 和边缘节点的问题，光靠服务端排查解决不了——得靠 CDN 部署和 Anycast 路由优化。