redis pub/sub不是可靠消息队列，需手动配置线程池防阻塞、避免复用jedispubsub、固定频道名设计、接受离线丢消息契约，关键在业务场景是否容忍丢失。
Redis 的发布订阅（Pub/Sub）在 Java 项目中不是“开箱即用”的消息队列，它本质是无状态、无持久化的广播通道。直接套用 Spring Boot 自动配置或简单 Jedis 调用，很容易掉进离线丢消息、线程阻塞、监听器失效的坑里。
Spring Boot 中 RedisMessageListenerContainer 必须手动配置线程模型
Spring Boot 默认的 RedisMessageListenerContainer 使用单线程处理所有频道消息，一旦某个 receiveMessage 方法执行慢（比如含远程调用或数据库写入），后续所有频道的消息都会排队卡住。
- 必须显式设置
setTaskExecutor，推荐用带拒绝策略的线程池：new ThreadPoolTaskExecutor().setCorePoolSize(4).setMaxPoolSize(8) - 不要复用 Web 容器线程池（如 Tomcat 的
taskExecutor），避免 HTTP 请求被 Pub/Sub 拖垮 -
container.setSubscriptionExecutor可选，但仅影响 SUBSCRIBE 建立连接阶段，不解决消息消费阻塞
JedisPubSub 实例不能复用，且必须在独立线程中运行
JedisPubSub 是有状态对象：内部维护订阅关系、接收缓冲区和中断标记。同一个实例被多次 subscribe() 或跨线程调用，会导致 onMessage 不触发、unsubscribe 失效，甚至 Jedis 连接卡死。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次订阅都应新建
JedisPubSub子类实例，例如：new JedisPubSub() { ... } -
jedis.subscribe(subscriber, "order.*")会阻塞当前线程 —— 必须包裹在new Thread(() -> { ... }).start()中 - 若需动态增删频道，改用
PSUBSCRIBE+PUNSUBSCRIBE，但注意通配符匹配性能随频道数线性下降
频道名设计直接影响可维护性与扩展性
看似只是字符串，但错误命名会让调试、监控、权限控制全部失效。比如用 "user:123" 当频道，意味着每用户一个频道 —— Redis 内部会为每个频道维护独立订阅者链表，10 万用户就是 10 万个频道结构，内存和 CPU 开销陡增。
- 优先用语义化固定频道，如
"order.created"、"inventory.updated"，配合消息体里的业务 ID 区分粒度 - 避免在频道名中拼接动态 ID；必须做时，改用分层模式：
"order.event.created"+ 消息体含{"orderId": "xxx"} - 若需多租户隔离，用 Redis database 切分（
spring.redis.database=2），别靠频道前缀硬扛
离线消息丢失不是 Bug，是 Pub/Sub 的设计契约
只要没在 SUBSCRIBE 后立刻收到 PUBLISH，就可能丢消息 —— 这不是网络问题，是 Redis 服务端根本不存未消费消息。很多团队试图用 LIST + BRPOP 模拟“可靠订阅”，结果把简单广播做成复杂队列，反而引入重复消费、ACK 管理等新问题。
- 确认场景是否真需要“不丢”：实时通知、状态刷新、监控打点，通常可以容忍丢；订单支付、资金流水，必须换
Stream或专业 MQ - 若坚持用 Pub/Sub，至少加一层轻量补偿：发布方同时写
SET order:123:pub_time "2026-07-13T16:17:00"，订阅方启动时查这个时间戳决定是否拉全量 -
Redisson的RTopic也遵循同一规则 —— 它只是封装了PSUBSCRIBE，没改变底层语义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
