Redis 多租户隔离的本质是在共享的缓存资源上构建出彼此独立、互不干扰的数据视图。由于 Redis 的命令执行模型是单线程的，数据本身没有原生的多租户隔离机制，因此方案设计需要从连接、Key 命名、命令权限和资源配额多个层面同时入手。如果只在应用层约定 Key 前缀，而缺乏底层强制约束，任何一处疏忽都可能让 A 租户的请求读到 B 租户的数据。
一、多租户隔离的核心维度与方案对比
多租户隔离通常可以从三个维度进行评估：数据面隔离、命令面隔离和资源面隔离。数据面隔离关注一个租户是否能访问到另一个租户的 Key；命令面隔离关注租户能否执行 FLUSHALL、CONFIG 等高风险命令；资源面隔离则关注单个租户是否会耗尽整个实例的内存、连接数或 CPU 时间。不同方案在这三个维度的表现差异很大，架构设计时不能只考虑其中一点。
从部署形态上看，常见的隔离方案有四种：独立 Redis 实例、独立 DB、Key 前缀约定以及 Proxy 代理层隔离。独立实例隔离性最强，每个租户拥有独立的进程和端口，互不影响，但成本最高，实例数量多时运维压力明显。独立 DB 虽然可以利用 Redis 的 SELECT 命令切换数据库，但 Redis 官方对多 DB 的支持并不鼓励，而且所有 DB 共享同一线程和内存池，只是一个逻辑命名空间，隔离强度较弱。
Key 前缀约定是最常见的轻量级方案，所有租户共享一个实例，通过 tenantId: 前缀区分数据，例如 1001:user:123 和 1002:user:123。这种方案实现简单、资源利用率高，但隔离完全依赖应用层自觉，一旦代码出现拼接错误或恶意绕过，就会产生跨租户访问。Proxy 代理层隔离则在客户端和 Redis 之间增加一层代理，由代理统一改写 Key 并校验权限，可以在不修改业务代码的情况下实现较强的隔离，但会引入额外的网络延迟和运维复杂度。
下表对比了四种方案在隔离强度、资源成本、运维复杂度和性能开销上的差异，可以作为选型参考。
| 隔离方案 | 隔离强度 | 资源成本 | 运维复杂度 | 性能开销 |
|---|---|---|---|---|
| 独立实例 | 高 | 高 | 高 | 低 |
| 独立 DB | 低 | 低 | 低 | 低 |
| Key 前缀 | 中低 | 低 | 低 | 低 |
| Proxy 代理 | 中高 | 中 | 中 | 中 |
在实际项目中，如果租户数量不多且对安全要求极高，独立实例是最稳妥的选择。如果租户数量较多但彼此信任度较高，Key 前缀加 ACL 授权可以兼顾成本和隔离。如果需要在不改动大量历史代码的前提下提升隔离等级，Proxy 代理层是更平滑的演进路径。
二、基于Key命名空间与Lua脚本的隔离落地
无论选择哪种方案，Key 命名规范都是隔离设计的第一步。推荐使用三段式结构：租户标识:业务域:业务键，例如 1001:order:20231201、1001:user:profile。租户标识必须从可信来源获取，比如已经通过认证的 JWT Token 或网关透传的租户上下文，不能直接信任客户端传入的任意参数。业务域用来对同一租户内的 Key 做逻辑分组，便于后续按域淘汰或统计。
仅靠开发规范约束 Key 前缀是不够的，还需要在底层通过 Lua 脚本强制隔离边界。Lua 脚本在 Redis 中具有原子性，可以在脚本内部拼接租户前缀并执行读写操作，这样即使应用层传入了不安全的 Key 后缀，也无法绕过前缀限制。下面是一个封装写入操作的 Lua 脚本示例，租户标识通过 KEYS 参数传入，脚本内部统一生成最终 Key。
-- 强制租户前缀的写入封装
local tenant_id = KEYS[1]
local key_suffix = ARGV[1]
local value = ARGV[2]
local ttl_ms = tonumber(ARGV[3])
local final_key = tenant_id .. ':' .. key_suffix
redis.call('SET', final_key, value)
if ttl_ms and ttl_ms > 0 then
redis.call('PEXPIRE', final_key, ttl_ms)
end
return final_key
在这个脚本中，KEYS[1] 由连接层或中间件注入，而不是由业务代码直接拼接。即使某个租户的应用逻辑存在缺陷，试图读取其他租户的 Key，只要脚本层面没有提供跨租户的入口，数据就不会泄漏。Lua 脚本的原子性还保证了前缀拼接与读写操作之间不会被其他命令插入，避免了并发下的竞态问题。
类似地，读取操作也应该通过统一的脚本或中间件进行。不建议直接在业务代码中使用 GET tenantId:key 这种裸命令，因为一旦租户 ID 拼接错误，就会访问到错误的数据。更稳妥的做法是把租户 ID 放到连接上下文中，由代理层或 Redis 客户端库自动拼接到所有 Key 前面，业务代码只感知相对的 Key 后缀。
三、租户配额管理与命令授权
即使数据边界被严格守住，一个租户仍可能通过大量写入或危险命令影响其他租户。Redis 6 引入的 ACL 机制可以按用户设置命令权限和 Key 模式限制，是实现命令面隔离的基础。可以为每个租户创建独立的 ACL 用户，只允许其访问以自身租户 ID 为前缀的 Key，并禁用 FLUSHALL、FLUSHDB、CONFIG、SHUTDOWN 等管理命令。
ACL SETUSER tenant_1001 on >tenant1001pass ~tenant_1001:* +@read +@write -flushall -flushdb -config -shutdown ACL SETUSER tenant_1002 on >tenant1002pass ~tenant_1002:* +@read +@write -flushall -flushdb -config -shutdown
上述配置中，~tenant_1001:* 表示该用户只能访问以 tenant_1001: 开头的 Key，+@read 和 +@write 开放常规读写命令，同时显式禁用了 FLUSHALL、FLUSHDB、CONFIG、SHUTDOWN 等命令。使用 ACL 后，即使应用层安全漏洞导致租户发出了恶意命令，也会在 Redis 服务端被直接拒绝，实现了安全兜底。
资源配额管理需要结合内存淘汰策略和连接数限制。可以在 Proxy 层或独立实例配置中为每个租户设置最大内存占用和最大连接数。对于共享实例的场景，可以通过 Redis 的 maxmemory 配合 volatile-lru 或 allkeys-lru 策略控制整体内存，但无法精确限制单个租户的内存用量。更细粒度的配额控制通常需要依赖 Proxy 层统计每个租户的 Key 数量和占用空间，或者直接为高优先级租户部署独立实例。
此外，Key 的 TTL 管理也是配额的一部分。对缓存类数据应默认设置过期时间，避免租户冷数据长期占用内存。可以在写入脚本中统一加入 TTL 逻辑，就像上面的 Lua 示例那样，由平台侧默认给每个 Key 设置合理的过期时间，而不是完全依赖业务方自觉。
四、高可用与扩展性考量
多租户隔离方案不能只考虑单机场景，还必须与 Redis 的高可用和集群架构兼容。如果使用 Redis Cluster，租户的 Key 会被分散到不同的哈希槽中。为了让单个租户的数据尽量落在同一个分片，可以使用哈希标签将租户 ID 放在花括号内，例如 {1001}:user:123。这样 Redis Cluster 在计算槽位时只对花括号内的 1001 进行哈希，保证同一租户的 Key 分布在同一个节点，便于事务和批量操作。
redis-cli -c SET {1001}:user:123 "alice"
redis-cli -c GET {1001}:user:123
随着租户规模增长，单个 Redis 实例或集群终会达到容量上限。这时需要考虑租户迁移策略。对于独立实例方案，可以将高负载租户迁移到独立的 Redis 实例，通过数据扫描和复制完成迁移。对于共享实例方案，可以按租户维度做数据分片，把不同租户分布到多个 Redis 集群，由一个路由层根据租户 ID 选择目标集群。这种分片方式可以减少单个集群的容量压力，同时保留租户之间的隔离性。
监控和告警是多租户系统稳定运行的重要保障。需要重点关注每个租户的内存占用、命令调用量、慢查询数量、错误率以及连接数变化。可以在 Proxy 层或应用层埋点统计这些指标，并配置阈值告警。例如当某个租户的内存增长率异常升高时，可能意味着该租户的业务出现缓存击穿或写入放大，需要及时干预，避免影响其他租户。
总结来看，Redis 多租户隔离没有一刀切的标准答案，需要根据租户数量、安全等级、成本预算和性能要求综合选择。数据面用统一的 Key 命名空间和 Lua 脚本强制前缀，命令面靠 Redis ACL 限制权限，资源面借助 Proxy 或独立实例做配额管理，再配合合理的集群分片和监控体系，才能构建出既安全又高效的 Redis 多租户服务。
Redis多租户隔离缓存隔离方案Key命名空间修改时间：2026-08-26 21:07:21