多租户SaaS场景下，CDN缓存键的核心设计原则是：缓存键必须包含租户标识，否则无论配置多少缓存规则，都存在串数据风险。
SaaS租户隔离怎么做，CDN缓存键的设计原则是什么
先讲一个真实场景，你的某个SaaS客户A上传了一张企业Logo，路径是/assets/logo.png，另一个客户B也上传了一张Logo，路径同样是/assets/logo.png，如果没有在缓存键里区分租户，CDN节点上这两个请求会命中同一份缓存客户B打开后台时,看到的却是客户A的Logo。
这就是SaaS租户隔离场景下缓存键设计要解决的第一性问题。
先搞清楚租户标识在哪个请求维度上
你需要回答一个问题：你的系统是怎么识别一个请求属于哪个租户的？
这个答案决定缓存键的设计方向。
- URL路径自带租户ID，比如
/tenantA/api/user和/tenantB/api/user，这种情况下租户信息天然在URL里，缓存键默认就能区分,风险最低。 - 请求头携带租户ID，很多SaaS后端走微服务网关，用
X-Tenant-ID这类自定义Header区分租户，问题在于CDN默认不把Header纳入缓存键计算,你需要显式配置。 - Cookie里存租户信息，这种场景最麻烦，Cookie参与缓存键会有两个隐患：一是CDN对Cookie的兼容性参差不齐；二是Cookie会频繁变化（比如登录态刷新）,强行纳入缓存键会大幅度降低缓存命中率。
- 通过子域名或独立Host区分，每个租户分配独立的子域名，比如
a.example.com和b.example.com，CDN本身就把域名作为缓存键的一部分,天然隔离。
缓存键设计的底线
行业共识认为,SaaS租户隔离下的缓存键设计需要守住三条底线：
- 保证不同租户的数据链路完全隔离,哪怕URL路径完全一致。
- 不能因为隔离而让缓存命中率崩塌，否则CDN就退化成回源代理,费用和时延都吃不消。
- 防止通过篡改请求参数读取他人缓存，你不仅要考虑正常业务下的隔离,还要考虑恶意请求绕过隔离机制。
这三条底线看似简单，但在实际设计中很容易顾此失彼,下面来看具体的方案对比。
多租户CDN缓存隔离方案对比，别只盯着命中率
不同租户标识承载方式，对应着不同缓存键设计,这里按完整度从低到高做个对比。
方案A：租户ID拼进URL路径，缓存键零改动
这个方案最直接，你在前端发起请求时，把租户ID放到path里，比如/v1/tenant_12345/users，CDN默认按完整URL生成缓存键,天然隔离。
优势是配置成本几乎为零,不需要动CDN控制台上的任何缓存键相关设置。
劣势也很明显：URL结构被租户信息污染，长期来看接口路径冗长，后端路由要额外解析租户ID，部分网关对URL长度有限制,路径层级过深时会有兼容性问题。
结论是：如果你的SaaS是轻量级应用，租户数量不大,这个方案够用且稳妥。
方案B：自定义请求头纳入缓存键
这是目前大型SaaS最常用的方案，租户ID放在X-Tenant-ID或业务自定义的Header里，在CDN控制台的“缓存键”配置中,把该Header加进计算范围。
具体操作路径一般是：CDN控制台 → 域名管理 → 缓存配置 → 缓存键 → 添加自定义Header参数。
这里有个关键操作细节：自定义Header参与缓存键之后，回源时也会带着这些Header，你要确保源站能正确接收和处理，如果CDN边缘节点处理不当，未携带该Header的请求会命中默认缓存副本，这需要你额外配置一条兜底规则,拒绝缺失租户标识的请求。
方案B的隔离强度和URL方案相当，但不会污染URL路径，代价是每次请求都会多几个字节的Header开销,以及配置成本。
方案C：子域名区分租户，用独立缓存空间隔离
严格来说这已经不是缓存键层面的设计，而是缓存空间层面的隔离，每个租户有独立域名,CDN为每个域名分配独立的缓存空间。
这个方案安全性最高，适合金融、医疗等强合规场景，劣势在于每个租户都需要独立的证书和域名配置，规模化之后运维成本会明显上涨，另外CDN通常按域名数量计费，从成本和运维两方面考虑，租户数量超过一定规模（比如几百个）时,这个方案性价比就会降低。
方案D：Cookie参与缓存键，多租户SaaS尽量避免
把Cookie中的租户标识纳入缓存键，从技术上讲可行,但实际项目中很少人这么干。
原因是Cookie的变化频率远高于Header或URL参数，用户浏览过程中Cookie可能被前端脚本反复写入，CDN缓存键只要有一点变化就会导致缓存未命中，如果整个缓存键里包含Cookie,命中率可能跌到大多数情况下不如不缓存的程度。
这里给一个明确建议：除非完全没有其他方案可选，否则不要用Cookie做缓存键扩展维度。
四种方案特征对比
| 隔离方案 | 隔离强度 | 回源压力 | 配置成本 | 适用规模 |
|---|---|---|---|---|
| 租户ID进URL | 中高 | 低 | 最低 | 小型SaaS，租户数量不大 |
| 自定义Header进缓存键 | 高 | 低 | 中等 | 中大型SaaS，需要精细控制 |
| 子域名独立缓存空间 | 最高 | 极低 | 高 | 强合规场景，租户数量较少 |
| Cookie参与缓存键 | 中 | 高 | 中等 | 不推荐在大多数情况下使用 |
CDN缓存键怎么配置才能既隔离又保命中率
搞清楚了方案，真正落地时还要分步骤操作，以最常见的“自定义Header进缓存键”为例,走一遍完整配置流程。
第一步：拆分静态和动态资源
所有需要CDN加速的请求先分两类。
静态资源（图片、CSS、JS、音视频）的缓存键可以在租户隔离的基础上做进一步优化比如你把租户ID放进缓存键，但css/js这类本身就是公共库的资源，如果所有租户都用同一套版本，可以考虑设置单独的缓存路径规则，不纳入租户维度，很多SaaS前端框架默认会为静态资源加上内容哈希，不同版本的哈希值不同,本身就可以安全地全局共享。
动态API接口则必须严格纳入租户维度的缓存键，哪怕两个租户请求同一个接口路径，只要X-Tenant-ID不同,就绝不能命中同一份缓存。
这里的判断标准是：这个响应内容是全局唯一还是租户私有。
第二步：配置缓存键规则
以主流CDN厂商的控制台为例：
- 进入“缓存配置”或“缓存键配置”页面。
- 选择需要配置的域名。
- 添加一条缓存键规则,指定参与计算的Header名单。
- 将租户标识Header（比如
X-Tenant-ID）添加到名单中。 - 保存后等待配置下发,一般几分钟到十几分钟生效。
第三步：解决命中率损失问题
缓存键里加了租户ID之后，意味着同一份内容要为每个租户单独缓存一份,这自然会带来命中率下降。
优化思路有三种：
- 为明显不同规模的租户设置不同缓存优先级，大租户访问量高，缓存副本能持续被复用；小租户访问量低，缓存副本可能还没被复用就过期了，这时可以给小租户设置更长的缓存时间,减少回源频率。
- 用分层缓存策略，CDN边缘节点之外，源站上方再挂一级中心缓存，即使边缘节点缓存未命中,中心缓存仍然能拦截大量回源请求。
- 与私有内容严格分离，文章开头提到的路径区分法在这里依然有效，尽可能把可共享的静态资源放到独立路径下,让公共部分走不含租户维度的缓存键。
配置完成后怎么验证缓存键真的隔离了
配置完不能只看面板上的“已生效”,必须做实际验证。
观察日志里的Cache Key字段
大多数CDN平台的回源日志或访问日志中，都会输出完整的缓存键信息，你在日志平台搜索同一个URL路径，如果看到两条记录分别来自不同租户、且缓存键中带有不同租户ID,就说明配置生效了。
手动构造测试请求进行验证
这个步骤业内专家建议一定要做,因为配置项之间的优先级有时候很隐蔽。
# 用租户A的身份请求 curl -H "X-Tenant-ID: tenant_a" https://your-cdn-domain.com/api/user/profile # 用租户B的身份请求 curl -H "X-Tenant-ID: tenant_b" https://your-cdn-domain.com/api/user/profile
观察两个请求的响应头，重点看X-Cache或Age字段，理想情况下两个请求都是MISS或都回源了，但它们的应该不同，如果你发现第二个请求命中了第一个请求的缓存，说明Header未正确参与缓存键计算,需要检查配置是否下发成功。
用命中率指标做长期观察
在CDN控制台的监控分析中，关注域名整体命中率变化，如果配置正确，命中率曲线应该是趋于平稳的，如果出现命中率短期骤降且持续不回弹，极有可能是缓存键粒度设置过细,或者误把动态请求纳入了缓存范围。
Q&A：CDN缓存键设计与SaaS租户隔离的常见疑问
静态资源也要做租户隔离吗？
不强制，如果静态资源本身是安全的公共资源（比如框架自带JS、公共样式表），所有租户可以安全共享，如果静态资源中包含了某个租户的私有数据（比如租户定制Logo、专属皮肤包），就必须加入租户维度的缓存键,判断标准是资源的访问权限控制范围。
用CDN缓存动态API接口，数据不一致的风险要怎么控制？
动态接口的数据一致性风险主要来自缓存时间设置不合理，建议将缓存时间控制在几秒到几分钟量级，同时对涉及敏感数据的接口设置Cache-Control: private响应头,从源站层面阻止CDN缓存。
多租户SaaS用同一个CDN域名，价格和性能上是否划算？
据工信部相关规定和CDN厂商公开信息，各厂商对同一域名下的缓存流量计费是统一的，不因请求URL和Header不同而额外计费，性能上如果缓存键包含租户维度导致命中率偏低，回源带宽成本会有所上升，但这通常远低于独立域名的证书和管理开销，多数情况下，合理配置的租户维度缓存键依然能为SaaS业务带来可观的回源流量削减,性价比优于每个租户单独配置CDN域名。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/645047.html
