Skip to main content

HTTP POST 请求超时（Read timed out）引起系统高负载排查

从你提供的错误日志截图来看，核心问题是：

HTTP POST 请求超时（Read timed out）
目标地址：http://192.168.95.80:6060/api/api/token
异常类型：ResourceAccessException → 嵌套异常是 SocketTimeoutException: Read timed out

🔍 问题详解

1. 发生了什么？

你的 Java 应用（通过 RestTemplate）尝试向内部服务 http://192.168.95.80:6060/api/api/token 发起一个 POST 请求，但在等待对方响应时超过了设定的读取超时时间，于是抛出异常。

简单说：

“我发了请求，但对方一直没回我数据，我等不及了，就报错了。”

2. 常见原因

✅ 网络或目标服务不可达/慢

  • 目标服务 192.168.95.80:6060 可能：
    • 没有启动
    • 崩溃了 / 卡死了
    • 正在处理耗时操作（如查数据库、调用第三方接口）
    • 防火墙/安全组拦截了请求（虽然能连上端口，但无响应）

✅ 超时设置太短

  • RestTemplate 默认的读取超时可能是几秒，如果目标服务需要更长时间处理，就会触发超时。
  • 特别是在获取 token 的场景中，可能涉及加密、鉴权、日志记录等耗时操作。

✅ 服务端资源不足

  • CPU、内存、线程池满、GC 停顿等都可能导致服务端无法及时响应。

✅ 中间件或代理层问题

  • 如果中间有 Nginx、网关、负载均衡器，它们也可能导致延迟或断开。

3. 关键线索

  • 错误发生在 SuqianHttpManager.postLightData(...) → 说明是你自己封装的 HTTP 客户端方法。
  • 调用链中有 RetryAnnotationAwareRetryOperationsInterceptor → 说明你可能配置了重试机制，但即使重试也失败了。
  • RedisMessageListenerContainer 出现在栈顶 → 可能是异步监听器触发的请求，比如收到某个消息后去刷新 token，结果失败。

🛠️ 解决方案建议

✔️ 临时缓解：增加超时时间

如果你确定目标服务只是“慢”，不是“挂”，可以延长 RestTemplate 的超时设置：

// 示例：自定义 RestTemplate 设置超时
RestTemplate restTemplate = new RestTemplate();
SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setConnectTimeout(5000);   // 连接超时 5 秒
factory.setReadTimeout(30000);     // 读取超时 30 秒（根据业务调整）
restTemplate.setRequestFactory(factory);

或者使用 HttpComponentsClientHttpRequestFactory（推荐用于生产环境）：

HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();
factory.setConnectTimeout(5000);
factory.setReadTimeout(30000);
RestTemplate restTemplate = new RestTemplate(factory);

💡 注意：不要盲目设得太大，否则会导致线程阻塞过久，影响系统吞吐量。

✔️ 根本解决：排查目标服务

登录到 192.168.95.80 服务器，检查：

  1. 服务是否运行？

    netstat -tlnp | grep 6060
# 或
ss -tlnp | grep 6060

  2. 查看该服务的日志（尤其是 /api/api/token 接口相关日志），看是否有报错、卡顿、死锁。

  3. 手动测试接口：

    curl -X POST http://192.168.95.80:6060/api/api/token \
     -H "Content-Type: application/json" \
     -d '{"your": "data"}' \
     --connect-timeout 5 \
     --max-time 30

    观察是否也能复现超时。

  4. 检查系统资源：

    top
free -h
iostat -x 1

✔️ 架构优化建议

  • 加熔断降级：使用 Hystrix、Sentinel 等，在多次超时后自动降级，避免拖垮主流程。
  • 异步化 + 队列：如果是非实时必须的 token 刷新，可放入消息队列异步处理。
  • 缓存 token：避免每次都要远程获取 token，本地缓存有效期的 token。
  • 健康检查 + 监控告警：对 192.168.95.80:6060 做定期探活，提前发现故障。

📌 总结一句话

你的应用调用内网 token 服务时因对方响应太慢或未响应而超时，需要么调大超时时间应急，要么深入排查目标服务为何变慢或不可用。

✅ 下一步行动建议：

  1. 先手动 curl 测试目标接口能否通、多久返回。
  2. 查看目标服务日志和系统负载。
  3. 根据情况决定是改超时参数，还是修复服务端性能问题。
  4. 长期考虑加入缓存、熔断、监控等健壮性设计。

如需进一步分析，请提供：

  • 目标服务的语言/框架（Spring Boot? Node.js?）
  • 当前 RestTemplate 的超时配置
  • 是否集群部署？有没有负载均衡？

我可以帮你定制具体解决方案。

No Comments
Back to top