不能。redis 6–7.0 的 acl 不支持 key 前缀通配符（如 ~tenant:a:），仅支持字面 key 名或 ~；7.0 起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。
Redis 6+ ACL 能否真正隔离不同租户的 Key 空间？
不能。ACL 本身不支持 Key 级别前缀过滤或通配符限制（比如 ~user:123:* 这类语法在 Redis 6–7.0 中**不被支持**），它只支持全局模式 ~*、单个 Key 名（~user:123:profile）或明确列出的多个 Key。这意味着：想靠 ACL 实现“每个租户只能访问自己前缀下的 Key”，必须提前知道所有 Key 名——这在多租户动态场景下不可行。
为什么 ACL SETUSER 配合 ~keypattern 会失效？
常见错误是这样写：
ACL SETUSER tenant_a on >pwd123 ~tenant:a:* +get +set
结果发现 tenant_a 仍能读 tenant:b:config，甚至报错 NOPERM 但行为不一致。原因有二：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis ACL 的
~后只接受字面 Key 名或~*，~tenant:a:*中的*是普通字符，不是通配符 —— 它等价于匹配一个叫tenant:a:*的具体 Key - 从 Redis 7.0 开始才引入实验性前缀匹配（需开启
acl-pubsub-default off并用~{prefix}*语法），但生产环境未广泛验证，且不支持嵌套通配（如~tenant:*:cache）
实际可行的多租户 Key 隔离方案有哪些？
绕过 ACL 的 Key 粒度限制，必须把隔离逻辑前置到应用层或代理层：
- 使用 Redis 代理（如
redis-shake、twemproxy或自研网关）：在请求到达 Redis 前校验KEYS/SCAN/DEL参数是否符合租户前缀规则，非法请求直接拒绝 - 客户端 SDK 封装：所有
SET/GET调用强制走tenantId + key拼接，并内置前缀白名单检查（例如只允许tenant:[a-z0-9]{8}开头） - 集群分片绑定租户：按租户 ID 哈希，将同一租户的所有 Key 固定路由到特定 master 节点，再配合
ACL限制该用户仅能连这个节点（需客户端支持节点直连 + 密码鉴权） - 退而求其次用数据库级隔离：为每个租户分配独立 Redis DB（
SELECT 1,SELECT 2…），再用ACL控制用户只能SELECT指定 DB —— 但注意 Redis 集群模式下SELECT命令被禁用，此法仅适用于主从或单节点部署
ACL 用户配置时最容易忽略的三个细节
即使不依赖 Key 前缀，ACL 权限组合也常因疏漏导致越权或阻断：
- 执行
SCAN需显式授权+scan，仅给+get不够；若用KEYS *（不推荐），还需+keys，但该命令在生产集群通常被禁用 - Pub/Sub 场景下，
~*不自动覆盖频道名，必须单独加~__sentinel__:*或~tenant:a:channel才能订阅 - 使用
ACL LOG查日志时，默认只记录失败事件；要看到完整权限决策链，得先执行ACL LOG RESET再设ACL LOG ON，否则容易误判拦截来源
Key 空间隔离的本质矛盾在于：Redis 的 ACL 设计面向运维人员管资源，而非应用层做租户沙箱。真要强隔离，得接受要么放弃集群直连（改用代理）、要么接受租户数据物理分离（多实例），或者把校验逻辑提到比 Redis 更高的层级——这点常常在压测后才暴露出来。
