limit_req_zone 实现的是请求限流隔离而非缓存隔离，它通过自定义请求头（如 X-Tenant-ID）构造业务维度限流键，实现租户级速率控制，从而间接保障缓存稳定性；真正缓存隔离需依赖缓存键前缀化或多实例命名空间等方案。
这其实不是缓存隔离，而是请求限流隔离——limit_req_zone 是 Nginx 的限流模块指令，不参与缓存控制。它无法实现“缓存隔离”，但可以配合自定义请求头（如 X-Tenant-ID、X-Region 或 X-Service-Name）实现**基于业务维度的精细化请求速率限制**，从而间接支撑缓存策略的稳定性与租户公平性。
明确：limit_req_zone 的作用边界
limit_req_zone 只负责按指定键（key）对请求进行速率统计和拦截，不读写任何缓存内容，也不影响 upstream 缓存行为（如 proxy_cache）。它的输出是“是否放行请求”，而非“是否命中缓存”。混淆二者会导致架构设计偏差。
如何用自定义头构造业务维度限流键
核心是把业务标识注入到限流 key 中，让不同租户/区域/服务的请求互不影响：
- 在客户端或网关层添加标准头，例如：
X-Tenant-ID: t-123、X-Region: cn-east-2 - Nginx 配置中使用
$http_x_tenant_id或$http_x_region作为 key 的组成部分 - 示例配置：
limit_req_zone $http_x_tenant_id zone=tenant_limit:10m rate=100r/s; limit_req_zone "$http_x_tenant_id|$remote_addr" zone=tenant_ip_limit:10m rate=5r/s;
- 注意：Nginx 默认忽略下划线，需开启
underscores_in_headers on;才能正确解析X-Tenant-ID
与缓存策略协同的关键点
虽然限流本身不缓存，但它可为缓存系统提供“业务维度治理”的前置保障：
- 防止单个租户突发流量打穿共享缓存后端（如 Redis 连接数/带宽超限）
- 避免热点租户挤占缓存资源，导致其他租户缓存 miss 率飙升
- 结合
proxy_cache_key使用相同业务头，确保缓存 key 与限流 key 维度对齐，便于问题归因 - 例如：缓存 key 设为
$http_x_tenant_id:$uri，限流 key 也用$http_x_tenant_id，两者形成统一业务切面
真正实现缓存隔离的推荐方式
若目标确实是“缓存隔离”，应转向以下更直接的手段：
-
缓存键前缀化：在应用层拼接租户 ID 到 cache key，如
cache:t-123:user:profile:1001 -
多实例缓存命名空间：Redis 使用不同 database（不推荐）或通过
tenant_id:前缀隔离；Spring Cache 配合自定义CacheResolver动态生成 cache name -
Laravel 多租户方案：启用
PrefixCacheTask，自动为每个租户设置独立缓存前缀 -
TypeGraphQL 字段级缓存：利用
@cacheControl装饰器按字段绑定不同 maxAge 和 scope（如scope: 'PRIVATE'）
