redis发布订阅无租户隔离能力，必须通过应用层强制实现：频道名须带tenant:{tenant_id}:前缀、服务端校验合法性、配合acl控制权限。

Redis发布订阅的频道本身不提供租户隔离能力

Redis 的 PUBLISH / SUBSCRIBE 是完全扁平的：只要知道频道名，任何客户端都能发或收。它没有内置的权限控制、命名空间隔离或租户上下文。这意味着，仅靠原生机制，tenant:123:alerts 和 tenant:456:alerts 这两个频道在 Redis 看来只是两个不同字符串——不会自动阻止租户 A 订阅租户 B 的频道，也不会限制租户 A 向租户 B 的频道发消息。

所以「隔离」必须由应用层主动设计和强制执行，Redis 只负责消息中转。

租户频道命名必须带唯一标识前缀

这是最基础也最关键的实践。所有频道名必须显式包含租户维度（如 tenant_id、org_code 或 workspace_uuid），且该字段需来自可信上下文（如 JWT payload、数据库查出的租户信息），不能由前端传入后直接拼接。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• ✅ 推荐格式：tenant:{tenant_id}:{event_type}（例如 tenant:abc123:order_updated）
• ❌ 避免格式：{tenant_id}:order_updated（缺少语义前缀，易与其他业务频道冲突）
• ❌ 严禁格式：{user_id}:order_updated（用户粒度太细，且 user_id 可能跨租户重复）
• ⚠️ 注意：如果租户 ID 含特殊字符（如 /、:、空格），必须做 URL-safe 编码（如用 encodeURIComponent 或 Base64），否则可能被客户端误解析或触发 Redis 协议异常

服务端必须校验订阅/发布的频道合法性

不能只靠约定，必须在每次 SUBSCRIBE 和 PUBLISH 前做白名单校验。比如某租户只允许操作以 tenant:abc123: 开头的频道，那么收到 SUBSCRIBE tenant:def456:log 请求时应直接拒绝并返回错误。

• 校验逻辑建议放在统一网关或消息服务中间件里，而非每个业务模块重复写
• 可缓存租户-前缀映射关系（如 Redis 中存 tenant:abc123:channel_prefix → "tenant:abc123:"），避免每次查 DB
• 对 PSUBSCRIBE 要特别小心：通配符（如 tenant:*:event）可能越权匹配其他租户频道，生产环境应禁止使用，或仅允许租户管理员级调用
• 示例校验伪代码：

  if (!channel.startsWith(`tenant:${tenantId}:`)) {  
    throw new Error(`Channel ${channel} not allowed for tenant ${tenantId}`);  
  }

连接与权限需配合 Redis ACL 控制（可选但强推荐）

单纯靠应用层校验存在绕过风险（如直连 Redis 的调试脚本、内部工具）。Redis 6.0+ 的 ACL 机制可进一步加固：

• 为每个租户创建独立用户（如 user tenant_abc123），仅授予对匹配频道的 PUBLISH / SUBSCRIBE 权限
• ACL 规则示例：

  ACL SETUSER tenant_abc123 on >secret123 ~tenant:abc123:* +subscribe +publish

• 注意：~ 后的 pattern 不支持通配符嵌套（如 ~tenant:*:* 是非法的），所以仍需按租户粒度配置
• 若用 Redis Cloud 或托管服务，确认其是否支持 ACL；部分旧版或精简版（如某些 AWS ElastiCache 配置）可能禁用 ACL

频道命名空间是租户隔离的起点，不是终点。漏掉校验、信任不可信输入、忽略 ACL，任何一个环节都可能让「隔离」变成幻觉。