subscribe 本质是阻塞式广播机制，无持久化、无ack、不保证送达，无法支持可靠事件通信；spring 通过 redismessagelistenercontainer 在独立线程中维护连接并回调 onmessage，绕过阻塞问题。
PUBLISH 和 SUBSCRIBE 能跑通，不代表事件驱动架构就稳了——它本质是“即发即弃”的广播机制，没持久化、没ACK、不保证送达，用错场景反而埋坑。
为什么不能直接用 SUBSCRIBE 做服务间事件通信
执行 SUBSCRIBE 后客户端会进入阻塞订阅模式，只能响应 UNSUBSCRIBE、PSUBSCRIBE、PING 等有限命令，不能再执行 GET、SET 或业务逻辑。这意味着：
- 你没法在一个连接里既处理业务又监听消息，必须拆成独立连接或线程
- 如果订阅进程崩溃或网络中断，离线期间所有消息永久丢失
- 没有重试、没有确认、没有消费位点，无法做幂等或回溯
-
SUBSCRIBE是面向连接的，不是面向消费者的，扩缩容时需手动管理连接数
Spring Data Redis 的 MessageListener 怎么绕过阻塞问题
Spring 封装了底层连接管理，用独立线程池维持长连接监听，把消息回调到你写的 onMessage 方法里，避免业务线程被卡住。关键点在于：
- 监听器注册后，框架自动创建专用
RedisConnection，与业务连接隔离 - 消息到达时触发回调，但回调本身不阻塞监听线程——你要确保
onMessage执行快，否则积压会堆积 - 默认不支持失败重试，异常抛出后该条消息就丢了；如需可靠投递，得自己加补偿逻辑或改用
Stream - 配置
RedisMessageListenerContainer时，setTaskExecutor推荐设为有界队列的线程池，防止单个慢消费者拖垮整体
PSUBSCRIBE 模式匹配适合哪些真实场景
PSUBSCRIBE 支持通配符（如 user.*、order:created.*），但它不是“模糊查询”，而是服务端逐个比对频道名，性能随订阅模式数量线性下降。适用情况包括：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 多租户系统中按租户前缀路由：订阅
tenant:123.* - 事件类型分级设计：
payment.success、payment.failed统一由payment.*处理 - 调试阶段临时监听一类事件，避免硬编码每个频道名
- 注意：
PSUBSCRIBE不支持嵌套通配符（如user.**.updated），且 Redis 6.0+ 才支持多个模式同时匹配
真正需要持久和可靠时，别硬撑 Pub/Sub
当你的业务要求“至少一次投递”“可追溯”“支持重放”或“跨服务事务一致性”，Pub/Sub 就不是合适选择。这时候该切到 Stream：
-
XADD写入带 ID 的消息，天然有序、可持久化 -
XGROUP创建消费者组，每个消费者有独立读取偏移量（DELIVERED状态可查） -
XREADGROUP支持 ACK 机制，失败可XACK或XCLAIM重试 - Spring Data Redis 也封装了
StreamMessageListenerContainer，接口风格和MessageListener类似，迁移成本低
Pub/Sub 的价值在“快”和“轻”，不是“稳”。选型时盯住 SLA：毫秒级延迟 + 允许丢消息 → 用 SUBSCRIBE；任何一条都不能丢 → 直接上 Stream。
