Redis不支持原生订阅分组，需通过层级化频道名（如order.payment.group-a）配合客户端逻辑实现；真正分组消费应改用Stream+XREADGROUP或专业消息中间件。
Redis 本身不支持原生的“订阅分组”语义，所谓“分组”必须靠频道名设计 + 客户端逻辑协同实现。 它没有 Kafka 那样的 consumer group 概念，SUBSCRIBE 是纯广播：只要订阅了同一频道，所有客户端都会收到每条 PUBLISH 消息。想做到“同组内只有一人消费”，得绕开 pub/sub，改用 Stream 或外加协调机制。
频道名怎么命名才能支撑“逻辑分组”
核心原则是：用层级化、可解析的频道名结构，把“业务域-子模块-分组标识”编码进去，例如 order.payment.group-a、user.profile.group-b。这样订阅方能按需匹配：
- 单组精确订阅：
SUBSCRIBE order.payment.group-a - 跨组泛订阅（如运维监控）：
PSUBSCRIBE order.*.group-*（注意：通配符订阅需启用pubsub-patterns，且性能略低于直连频道） - 避免使用动态生成的随机 ID 作频道后缀（如
order.123456），否则无法形成稳定分组边界 - 频道名中不要含特殊字符（空格、逗号、中文等），只用 ASCII 字母、数字、点
.、短横线-、下划线_
为什么不能靠 UNSUBSCRIBE + 重连模拟“组内负载均衡”
有人尝试让多个实例轮询 UNSUBSCRIBE/SUBSCRIBE 同一频道，试图制造“只有一个在线”的假象——这在 Redis pub/sub 下不可靠：
-
UNSUBSCRIBE不是原子操作，网络延迟或命令丢失会导致残留订阅 - 发布者发消息时，只要频道有至少一个订阅者，消息就立刻广播出去；不存在“等待组内选主”的中间状态
- 客户端断连后，未接收的消息直接丢弃（pub/sub 无消息回溯），根本谈不上“重新分配”
- 频繁重连会触发 Redis 的
client-output-buffer-limit限制，可能被踢出连接
真正需要分组消费？别硬扛 pub/sub
如果你的场景本质是“一组消费者竞争消费同一批消息（如订单处理集群）”，Pub/Sub 就不是正确工具。该换用：
-
Stream+XREADGROUP：天然支持 consumer group、pending list、ACK 机制，消息可重播、可确认、可分配 - 搭配 Redis 的
SETNX+ 过期时间做简易选主，再由主节点统一调用PUBLISH，但复杂度高、易出竞态 - 引入专业消息中间件（如 RabbitMQ、Kafka），当业务规模上升后，pub/sub 的无持久、无 ACK、无重试缺陷会集中爆发
频道名规则只是表层控制，真正的分组语义必须由上层协议或存储模型承载。别在 pub/sub 上补丁式加逻辑，容易越补越脆。
