MCP Server 缓存：在经历 87 次宕机后的经验教训
我原以为我的 MCP server 不需要缓存。
我的知识库只有几千条条目。查询速度很快。但我错了。
在经历了 87 次生产环境宕机和三天的超时调试后，我吸取了一个惨痛的教训。每个 MCP server 都需要缓存，即使是小型 server 也不例外。
以下是事情的经过。
Server 使用语义搜索来查找笔记。大多数时候它运行良好。但随后，问题出现了。
- 请求中途连接断开。
- Claude Desktop 在 60 秒后超时。
- Nginx 返回 504 Gateway Timeout。
最糟糕的部分？这只发生在重复查询时。
当用户两次询问同一个问题时，在 AI 思考期间，连接可能会处于空闲状态。随后代理（proxy）会断开连接。Claude 会自动重试请求。现在，你同时运行着两个完全相同的搜索。
当发生多次重试时，你的数据库连接池就会耗尽。一切都会崩溃。
我意识到我不应该缓存 AI 的最终响应。对于 MCP 来说，那太复杂了。相反，我必须缓存耗时最长的部分：语义搜索和内容获取。
我转向了二级缓存策略：
• 第一级：用于频繁查询的内存缓存（In-memory cache）。速度极快。 • 第二级：用于在重启后共享数据的 Redis 缓存。
我还遵循了以下规则来确保其生效：
- 规范化查询：我将查询转换为小写并移除多余的空格。这可以提高缓存命中率。
- 缓存结果而非流（streams）：我只缓存搜索结果。搜索过程占用了 95% 的时间。
- 优雅降级：如果 Redis 宕机，server 仍能工作，只是会直接访问数据库。缓存是一种优化手段，而不是请求成功的必要条件。
效果非常显著。
我的平均搜索时间从 320ms 降到了 12ms。速度提升了 27 倍。我的总缓存命中率为 73%。大多数查询根本不会访问我的数据库。
如果你要构建 MCP server，请这样做：
- 个人使用：使用内存缓存。它可以防止随机超时。
- 公共服务：使用带有 Redis 的二级缓存方案。它可以防止崩溃并提高速度。
缓存关乎可靠性。它能打破重试和连接失败的恶性循环。
Optional learning community: https://t.me/GyaanSetuAi