通过提前调用API预热缓存的最佳实践选型咨询

从你的高TPS服务场景出发，方案2是更稳妥的选择，理由如下：

• 流量隔离避免互相干扰：高TPS服务中，用户正常请求的流量基数本就很大，若将预热缓存的请求混入现有Fetch API，一旦触发批量预热（比如响应SNS事件做大规模缓存刷新），很容易挤占正常请求的资源，导致用户侧延迟上升，完全违背了你做预取缓存降延迟的初衷。分开API能实现流量的物理隔离，各自的限流、监控规则可独立配置，不会出现互相 throttle 的问题。

• 职责清晰易维护：预取API专门负责缓存写入（预热），现有Fetch API专注于缓存读取+按需回源，单一职责的设计让代码逻辑更清晰，后续排查问题、扩展功能（比如给预取API加批量预热能力、权限控制）都更便捷。

针对方案2的缺点，可通过以下方式降低影响：

• 复用核心逻辑：预取API无需从零开发，完全可以复用现有Fetch API里与下游交互、缓存写入的核心代码，仅新增一个API端点做简单封装，开发量并不会大幅增加。
• 基建复用：如果你的服务已有API网关、服务框架，新增一个API无需额外搭建过多基础设施，只需在现有架构中添加路由配置即可。

另外，针对你提到的响应SNS事件预热的场景，单独的预取API更适合作为事件触发的目标端点——SNS事件触发的批量请求可直接调用预取API，无需与用户流量混杂，还能灵活调整预热并发量，避免冲击服务。

内容的提问来源于stack exchange，提问作者user1542422