负载均衡与缓存需协同工作：负载均衡分流流量，缓存拦截重复请求；缓存应分层部署（cdn、反向代理、分布式、本地），按路径与业务特征精准缓存，并通过监控联动保障实效。
负载均衡和缓存不是“二选一”，而是协同工作的组合拳：负载均衡负责把流量分出去，缓存负责把重复请求拦下来。真正降低集群负载的关键，在于让两者各司其职、互相配合——既不让缓存成为单点瓶颈，也不让负载均衡盲目转发本可本地响应的请求。
明确缓存层的部署位置
缓存不是越靠近用户越好，而是要放在能拦截最多无效穿透的位置：
- 边缘缓存（CDN）：适合静态资源（JS/CSS/图片），由CDN节点就近响应，完全不触达你的后端集群；
- 反向代理缓存（如Nginx）：部署在负载均衡器之后、应用集群之前，适合缓存API响应、聚合页面、带版本号的资源，是降低存储/计算集群压力最直接的一层；
- 分布式缓存（Redis/Memcached）：放在应用层与数据库之间，专注缓解读密集型查询压力，尤其适合热点数据、会话状态、计数类信息；
- 本地缓存（Caffeine/Guava）：嵌入应用进程内，响应最快，但容量有限、不共享，适合作为Redis前的“最后一道缓冲”。
让负载均衡避开已缓存路径
如果所有请求都先过负载均衡再进缓存，就浪费了缓存的价值。应优先在入口处做路径分流：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对/static/、/assets/、/api/v1/config等明确只读且低变的路径，Nginx直接缓存并返回，不转发到后端集群；
- 对需要鉴权或个性化的内容（如/user/profile），负载均衡直接转发，跳过代理层缓存，交由应用层用Redis按用户ID缓存；
- 配置
proxy_cache_bypass和proxy_no_cache，自动识别含Cookie、Authorization头或POST方法的请求，确保私有/写操作不被缓存。
缓存策略必须匹配业务特征
缓存失效时间不能拍脑袋定，要结合数据更新频率和容忍度：
- 商品详情页（每天更新1次）→ 缓存10分钟，用Cache-Control + ETag双校验；
- 首页推荐位（每小时轮换）→ Nginx缓存30分钟，配合主动purge机制；
- 用户头像（URL含MD5哈希）→ 缓存1年，靠URL变更自然失效；
- 404响应（防恶意爬虫刷）→ 只缓存30秒，避免错误长期滞留。
监控与联动才是持续有效的保障
缓存是否真在减负，得看数据，而不是配置文件：
- 关注Nginx的
$upstream_cache_status变量，统计HIT/MISS/BYPASS比例，低于85%需排查缓存键设计或响应头设置； - Redis监控key数量、内存使用率、命中率（建议>95%），命中率骤降往往意味着缓存穿透或雪崩；
- 负载均衡后端节点的CPU、连接数、5xx错误率，若缓存生效，这些指标应随缓存命中率上升而明显下降；
- 把缓存清理动作（如发布新版本时清Redis key）接入CI/CD流程，避免人工遗漏导致脏数据。
