redis pub/sub 本身不支持租户隔离，需通过服务层强制频道名带租户前缀（如tenant:abc123:order:created）并校验，禁用psubscribe，推荐升级至stream+consumer group实现天然隔离。
Redis Pub/Sub 本身不支持租户隔离
Redis 的 PUBLISH / SUBSCRIBE 是全局的：只要频道名相同，所有客户端都能收发消息，不管连接来自哪个租户。没有内置的命名空间、ACL 频道前缀控制或租户级权限开关。硬靠文档说“不同租户用不同 Redis 实例”不是错，但成本高、运维重，多数场景不现实。
用租户 ID 前缀强制频道命名规范
最轻量、最常用且有效的做法是：所有频道名必须以租户标识开头，例如 tenant:abc123:order:created 或 t_abc123_notifications。这不是 Redis 功能，而是服务层的强约束。
- 发布方必须从请求上下文（如 JWT claim、HTTP header、DB 查询）提取
tenant_id，拼接后调用PUBLISH tenant:abc123:alarm:high - 订阅方启动时，只订阅自己租户的频道，绝不能用
PSUBSCRIBE tenant:*:*这类通配——它会跨租户漏收 - 若用 Spring Data Redis，
RedisMessageListenerContainer的addTopic()必须传入完整带前缀的频道名，不能依赖配置自动注入 - 注意：Redis 不校验频道名合法性，
tenant:::foo或tenant:..:bar也能发，但后续排查困难，建议在 SDK 层做格式校验
避免用 PSUBSCRIBE 做租户路由
PSUBSCRIBE 支持 glob 模式（如 tenant:abc123:*），看起来很适合租户隔离，但有严重隐患：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 一个连接只能有一个
PSUBSCRIBE模式匹配逻辑，无法动态增删租户频道（比如租户切换、权限变更后不能热更新） - 模式匹配性能随订阅数线性下降，Redis 官方明确提示：
PSUBSCRIBE在大量 pattern 下会导致 SUBSCRIBE 延迟升高 - 某些 Redis 代理（如 Twemproxy、AWS ElastiCache 集群模式）根本不支持
PSUBSCRIBE，直接报错ERR unknown command `PSUBSCRIBE` - 测试时容易漏掉边界 case：比如
tenant:ab:events会被tenant:a*错误匹配
更安全的替代方案：用 Stream + consumer group
如果业务允许升级 Redis 版本（≥5.0），Stream 是比 Pub/Sub 更适合多租户的原语。每个租户独占一个 stream（如 stream:tenant:abc123:notifications），并创建专属 consumer group（如 cg-abc123-worker）。
-
XADD stream:tenant:abc123:log * level "error" msg "timeout"—— 写入带租户前缀的 stream -
XGROUP CREATE stream:tenant:abc123:log cg-abc123-worker $ MKSTREAM—— 每个租户独立 group，天然隔离 - 消费者用
XREADGROUP GROUP cg-abc123-worker worker1 COUNT 10 STREAMS stream:tenant:abc123:log >，不会看到其他租户数据 - Stream 支持消息持久化、ACK 重投、pending list 查看，比 Pub/Sub 更可靠；但注意内存占用略高，需配合
MAXLEN或EXPIRE清理
租户隔离的关键不在 Redis 能力，而在服务层对频道/Stream 名的生成、校验与生命周期管理。最容易被忽略的是：上线前没做租户 ID 注入链路审计——比如某个定时任务绕过网关，用默认租户 ID 发布，结果全租户收到同一条告警。
