Redis Pub/Sub适合通知告警、配置热更新、轻量级聊天及事件解耦等实时广播场景，因其低延迟、无状态、零配置，但不保证消息持久化、投递成功或顺序，故不可用于订单支付等强一致性业务。
Redis Pub/Sub 不适合做微服务间的核心业务消息总线，但作为轻量级事件通知通道，在特定场景下确实能快速见效。
哪些场景真能用上 Pub/Sub？
它只适合“丢了不关键、来了就处理”的实时广播类需求：
- 服务健康状态心跳：每个实例定时
PUBLISH自己的存活信号，监控服务SUBSCRIBE所有实例频道，断连即告警 - 配置热更新通知：配置中心改完配置后
PUBLISH一个config:reload消息，各服务收到后主动拉取新配置 - 开发/测试环境日志透出：把
log:debug频道开放给本地调试工具，避免侵入式日志收集
注意：这些都不依赖消息不丢失，也不需要顺序或重试。
为什么订单、支付不能走 Pub/Sub？
根本原因是 Redis Pub/Sub 没有消息确认和持久化机制：
- 订阅者进程重启后，断连期间所有
PUBLISH消息直接丢弃，onMessage回调永远不会触发 - 没有 ACK 机制，发布端完全不知道谁收到了、谁没收到
- 多个订阅者收到同一条消息（广播语义），不是队列式分发，无法做负载均衡
比如订单创建后要扣库存，如果库存服务刚好在那一刻网络抖动掉线，这条消息就永远消失了——这不是“允许丢失”的范畴。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Spring Data Redis 的 RedisMessageListenerContainer 容易踩什么坑？
它封装了底层连接管理，但默认行为容易让人误以为很可靠：
- 自动重连后不会自动恢复订阅，必须在
onConnect回调里手动调用subscribe()，否则静默失订 -
PatternTopic("order.*")看起来灵活，但通配符匹配是 CPU 密集型操作，频道数超 1000 时会明显拖慢 Redis 主线程 - 同一个
RedisMessageListenerContainer实例注册多个MessageListener，它们共享线程池，一个监听器阻塞会拖慢全部
别把它当成 RabbitMQ 或 Kafka 的平替，它的设计目标从来就不是可靠投递。
PUBLISH 和 SUBSCRIBE 的连接隔离为什么必须做？
Redis 进入订阅模式后，该连接就只能处理 Pub/Sub 命令：
- 如果复用同一个
Jedis或RedisTemplate实例既发SET又做SUBSCRIBE，后续GET会直接报错：ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / QUIT allowed in this context - HTTP 请求里临时开个
SUBSCRIBE（比如 Spring MVC Controller 里调用），请求一结束连接就关，订阅立即失效 - 正确做法是：用独立连接池 + 长生命周期的后台线程维持
PubSub连接，和业务数据操作彻底分开
这个连接模型限制是 Redis 协议层决定的，绕不开，也别试图 hack。
