中间件专题：系统的压力转移与受力点

系统一旦扛不住压力，最先暴露问题的往往不是业务逻辑，而是中间件这一层——数据库连接池被打满、上传接口占满带宽、多个实例抢着跑同一个任务。这组专题就是围绕这些真实故障场景展开的：每一篇都以一个具体的症状开头，讲清楚这类中间件在链路里到底卸下了哪部分压力、又带来了哪些新麻烦。建议先对照下面的症状描述，找到和自己遇到的问题最像的那一篇再深入读，而不是从头到尾顺序看完。

1. 按工程症状定位专题

以下各专题均围绕特定的系统压力症状展开，建议根据当前系统所呈现的异常信号选择对应章节进行深入研读：

• 缓存：读路径的副本治理与泄压阀
  • 症状：SQL 查询逻辑无误，但高频热点流量导致数据库连接池耗尽，P99 延迟失控。
• 消息队列：异步执行链与最终一致性
  • 症状：单次同步请求涉及多个长时 I/O（如 OCR + 向量化），导致用户等待超时，且失败后无从补救。
• 搜索与检索：从数据库镜像到证据引擎
  • 症状：数据库中存在目标数据，但用户无法通过搜索命中；或关键词匹配粒度过粗，语义相似的内容无法被召回。
• 对象存储：带宽脱离与元数据解耦
  • 症状：大文件上传/下载占用应用服务器带宽，或 PDF 派生的预览图、切块文件缺乏统一版本管理与生命周期治理。
• 配置、发现与协调：多实例系统的现实对齐
  • 症状：多台机器持有不一致的配置（视图漂移），或多个 Cron 任务在不同实例上并发执行（选主失效）。

2. 工程审计的四个核心维度

研读每一篇专题时，应围绕以下四个维度进行系统性梳理：

1. 最小结构：该组件的核心对象是什么？
2. 受力点：它在链路中抵御了哪一类不确定性？
3. 副作用：引入它之后，系统新增了哪些一致性问题或运维成本？
4. 排查序列：发生故障时，第一排查现场在哪？

架构选型原则： 中间件的引入决策应以解决明确的系统压力点为前提，而非追求技术栈的丰富程度。若一个组件无法明确改善 P95 延迟或系统稳定性，其引入本身即构成技术债。中间件的核心工程价值在于将主业务链路从繁重的非业务负担中解耦。