进程内缓存
实现简单、延迟最低，适合单实例或读多写少的场景。为什么不能长期用：多副本之间无法共享，扩容后命中率被摊薄，重启即清空。边界是缓存内容不能含跨用户数据，否则实例间隔离失效会带来越权风险，这一点最容易被忽视。
独立缓存集群
集中部署便于共享与治理，能承载较高并发。怎么做：按业务分库分键前缀，设置内存上限与驱逐策略；边界是集群本身成为关键路径，必须做主从与容量水位告警，否则一次抖动会拖垮全部业务，恢复时间也不可控。
统一网关层
把鉴权、脱敏、限流、路由与审计收敛到一层，业务只对接一个入口。为什么推荐：换模型或换供应商时改配置即可，不必逐系统改造。边界是网关要按关键系统运维，双活或快速切换要提前设计，不能当成附属组件临时上线。
边车与多租户隔离
每个租户或业务独立边车，故障与配置互不影响，适合强隔离要求。代价是资源占用与升级管理更复杂。怎么做：用统一模板下发配置并集中采集指标；边界是边车数量增长后排障难度上升，需要自动化支撑，否则运维会被拖住。
多级组合
常见组合是进程内做热点、集群做共享、网关做策略。为什么有效：不同层承担不同职责，命中率与治理各得其所。边界是层级越多，失效传播越难控制，要统一版本号与失效事件，避免各层各自为政，出现新旧答案并存。
适用与不适用
适合谁
- 用户量增长后命中率下滑、需要调整架构的 SaaS 团队
- 有多租户隔离要求的平台型业务团队
- 正在设计模型接入层与统一网关的技术负责人
不适合谁
- 单实例部署、并发很低的内部工具
- 没有运维能力、也不接受多组件管理的团队
典型场景
某 SaaS 服务商的智能助手在客户增长后命中率下滑，排查发现是进程内缓存随扩容被摊薄。团队改为集群共享缓存加统一网关，网关按租户做限额与脱敏；高安全要求的两个客户单独部署边车。迁移分两批灰度，观察一周后才全量切换。
可执行步骤
- 统计当前并发、峰值与缓存内容的数据敏感度，形成一页可评审的说明
- 按隔离要求把业务分成共享与独占两类，明确各自的边界与责任人划分
- 先做单层方案并测命中率与延迟，记录可对比的基线数据与统计口径
- 引入网关统一策略，并注入故障验证切换、限流与审计是否都能生效
- 分批灰度迁移，保留可回退到旧链路的开关、明确责任人与完成时限
常见坑
- 为省事把用户相关数据放进进程内缓存，扩容后实例间互相不可见，出现越权或答案错乱。
- 缓存集群没有容量水位告警，内存打满后大量驱逐，命中率瞬间归零，后端被打出大量错误。
- 网关当附属组件部署，没有双活与容量评估，成为全站单点，故障时业务整体不可用且难以降级。
- 边车数量增长后仍手工改配置，版本不一致导致行为差异，排障时找不到原因与责任人是谁。
自检与验收清单
- 缓存内容是否已按敏感度分类并经过业务评审
- 共享与独占业务是否划清边界并明确责任人分工
- 缓存集群是否配置主从复制与内存水位告警项
- 网关是否有双活方案与可执行的切换、回退预案
- 迁移是否保留可用回退开关，责任人是否明确
常见问题
必须上独立缓存集群吗？
不一定。并发低、单实例部署时进程内缓存足够，还能省掉一跳网络。判断依据是副本数量、命中率要求与数据是否跨用户共享，盲目上集群会多出一套需要值守的关键路径。
网关会不会成为瓶颈？
会，如果按旁路组件对待。网关处在关键路径上，需要做容量评估、双活与限流降级；选型时先看它能否水平扩展与配置热更新，再谈策略功能，否则功能越多越容易出问题。
多级缓存怎么保证一致？
统一版本号与失效事件是关键：写入时先让上层失效，再广播到集群，读时校验版本。允许短暂不一致时要在产品上说明，例如提示信息可能有延迟，不能默认用户感知不到。