概要

“这个接口昨天还是 200ms，今天突然变成 5 秒。”

遇到这类问题，最危险的做法是立即改线程池、加缓存或者重启服务。它们有时能暂时缓解问题，却可能掩盖真正原因，并给系统引入新的不确定性。

我做过中台慢接口治理、性能边界压测和高并发服务调优。面对接口变慢，我通常按照“先界定范围，再沿调用链缩小问题”的方式排查，重点检查以下五个位置。

一、先确认“慢”发生在哪里

第一步不是看代码，而是建立事实：

• 是平均耗时变慢，还是 P95/P99 尾延迟变慢？
• 是所有请求都慢，还是某类参数、租户或数据范围慢？
• 是单个实例慢，还是所有实例慢？
• 从什么时间开始？期间是否有发布、配置、数据量或流量变化？
• 服务端处理慢，还是网关排队、客户端网络或重试造成的慢？

高级 Java 与 AI 应用工程（三）：数据库、中间件与流程编排

技术定位

关系型数据库保存业务事实与事务约束；Redis 处理低延迟的临时状态；RabbitMQ 负责异步传递与削峰；Elasticsearch 提供搜索、聚合与向量召回；工作流引擎管理长生命周期的人机流程。它们各自解决不同问题，不能互相替代。

1. 关系型数据库：事实与事务的来源

MySQL、PostgreSQL、GaussDB、Oracle 的 SQL 细节不同，但设计原则一致：以约束保护数据，以索引支撑访问路径，以执行计划证明性能。