为什么我们从关键 API 中移除了缓存

Source: Dev.to

引言

当我们想到 API 中的数据缓存时，往往会联想到更快的响应时间、更少的数据库调用以及整体更好的性能。API 越关键（例如金融类），缓存带来的好处就越多。然而，在某个特定场景下，缓存却成了瓶颈。

背景

所讨论的 API 是一个基于 Spring Boot 构建的本地部署 REST 端点，集成了众多系统。它在生产环境中运行良好，但为了实现更高的可扩展性、稳定性以及在高可用、多实例模式下运行，团队需要重新审视其架构。

考虑的方案

• 分布式缓存（例如 Redis） – 会引入新组件、增加维护开销，并需要额外的技术能力。
• 在实例之间同步 Spring 缓存 – 由于经典的缓存失效问题，容易出错。
• 彻底移除缓存 – 在经过充分讨论后最终被选中。

移除缓存的原因

1. 缓存同步的复杂性 – 跨实例的自定义机制脆弱。
2. 基础设施成本 – 引入 Redis 会带来额外的组件和运维负担。
3. 写密集型工作负载 – API 的写操作多于读操作，缓存导致不必要的查询。
4. 读取流量低 – 心跳检查每 30 秒一次，其他读取流量并不显著。
5. 流量增长逐步 – 业务量增长缓慢，而非指数级。
6. 即将进行云迁移 – 计划在未来 12 个月内重新设计，轻量化设计更为合适。
7. 高可用性要求 – 必须通过设计实现，而不是偶然达到。

权衡

此决定在性能上带来适度的下降，但换来了更好的高可用性、稳定性和简洁性。负载测试表明，对响应时间的影响在可接受范围内。

经验教训

• 像缓存这样的最佳实践在使用前必须评估其适用性。
• 需要考虑部署环境（本地 vs. 云）、数据负载、消费者规模、非功能性需求以及长期影响。
• 过度工程往往会带来比解决的问题更多的问题。

结果

API 变得更精简，能够在多个实例中运行而不担心数据陈旧，并达成了高可用性目标。团队现在拥有一个更简单、更易维护的服务，为未来的云迁移做好了准备。