3. API Gateway 缓存场景分析：哪些 API 适合缓存，哪些不适合

在 API Gateway 中接入缓存中间件并非“一刀切”的策略。错误的缓存决策不仅浪费内存资源，还会导致数据不一致、用户看到过期信息等严重问题。本章从读写比例、数据一致性要求、数据时效性三个维度，系统梳理适合与不适合缓存的 API 场景，并给出缓存粒度的选择依据。

3.1 缓存适用性判断模型

判断一个 API 是否适合缓存，核心依据是以下三个维度的交叉评估：

3.2 适合缓存的 API 场景

以下三类 API 是缓存中间件的最佳实践对象，缓存命中率通常可达到 70% 以上：

• 基础数据查询类： 如商品分类列表、国家/地区代码、配置字典、静态标签。这些数据几乎不变，一次写入缓存后可长期复用。
• 用户无关的聚合数据： 如首页推荐位、热门文章排行榜、公告信息。所有用户看到的内容相同，缓存一份即可服务所有请求。
• 低频变化的业务数据： 如产品规格参数、门店营业时间、运费模板。数据变更频率以小时或天为单位，缓存 TTL 可设置为 5~30 分钟。

3.3 不适合缓存的 API 场景

以下场景强行使用缓存会带来负面效果，应避免或采用特殊策略：

3.4 缓存粒度选择：全响应缓存 vs 部分数据缓存

确定 API 适合缓存后，还需要选择缓存的粒度。粒度选择直接影响缓存效率、内存占用和失效复杂度。

3.4.1 全响应缓存（Full Response Caching）

将整个 HTTP 响应（包括 Headers 和 Body）作为缓存键值存储。适用于：

• 响应内容完全公共，不依赖用户身份或请求参数中的个性化信息
• 响应体较小（通常 < 100KB）
• 数据变更频率低，缓存失效策略简单

// 全响应缓存示例（基于网关路由配置）
GET /api/v1/categories
Cache-Control: public, max-age=300
X-Cache-Key: /api/v1/categories

// 缓存命中时直接返回完整响应，无需回源

3.4.2 部分数据缓存（Partial Data Caching）

仅缓存响应中的公共数据片段，个性化部分在网关层动态组装。适用于：

• 响应中大部分数据是公共的，但有小部分用户个性化内容
• 响应体较大（如 500KB+），全量缓存内存开销过高
• 需要精细控制缓存失效范围，避免因小部分数据变化导致整个缓存失效

// 部分数据缓存示例（网关层模板组装）
// 1. 从缓存获取公共数据片段
GET cache://product/{id}/base_info  →  {"name":"...", "price":99.9, "images":[...]}

// 2. 从用户服务获取个性化数据
GET user://favorites?uid={userId}  →  {"is_favorited": true}

// 3. 网关层合并响应
{
  "product": <cached_base_info>,
  "user_status": <personalized_data>
}

3.5 缓存粒度对比总结

3.6 场景决策速查表

以下速查表帮助架构师快速判断常见 API 的缓存策略：