不能直接用ReactiveRedisDataSource做Pub/Sub，因其仅封装命令式数据操作，不暴露响应式订阅API；SUBSCRIBE需独占连接并长期存活，官方为防状态污染默认屏蔽该能力，须改用Vert.x Redis Client原生接入。
为什么不能直接用 ReactiveRedisDataSource 做 Pub/Sub
Quarkus 官方的 ReactiveRedisDataSource（基于 SmallRye Redis）不暴露 Pub/Sub 的响应式 API。它封装的是命令式数据操作（get、set、keys 等），而 SUBSCRIBE 会将连接永久切换到订阅模式——此时该连接不能再执行任何非 Pub/Sub 命令，且必须长期存活。官方客户端为避免状态污染，默认屏蔽了这一能力。
必须用 Vert.x Redis Client 原生接入
Quarkus 的 vertx-redis-client 扩展提供了底层 RedisClient 实例，它支持完整的 Pub/Sub 生命周期管理。你需要手动注入并持有这个 client，而不是走 ReactiveRedisDataSource。
- 在
pom.xml中确保启用：quarkus-vertx-redis - 通过
@Inject RedisClient redisClient获取实例（注意不是ReactiveRedisDataSource） - 调用
redisClient.subscribe("channel")启动监听，返回Uni<void></void> - 消息到达时，通过
redisClient.onMessage()注册回调，参数是RedisMessage
示例片段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redisClient.subscribe("order-events")
.onItem().invoke(v -> {
redisClient.onMessage(msg -> {
String channel = msg.getChannel();
String payload = msg.toString();
log.info("Received on {}: {}", channel, payload);
});
});
如何避免连接断开后收不到消息
Vert.x Redis client 默认不自动重连，SUBSCRIBE 失败或网络中断后，监听就彻底停止——这是最常被忽略的问题。
- 不要依赖单次
subscribe()调用；要用Uni.repeat().withDelay()或定时轮询重试 - 在
onFailure()中显式调用redisClient.close()再重建 client，否则旧连接可能泄漏 - 务必在应用生命周期内管理：用
@Observes StartupEvent启动订阅，用@Observes ShutdownEvent清理（调用unsubscribe()+close()） - 别在 HTTP 请求里动态 subscribe——短命请求无法维持长连接
消息广播语义与多实例部署的坑
Redis Pub/Sub 是“频道级广播”：所有订阅同一频道的客户端（无论在哪台机器上）都会收到每条消息。这在 Quarkus 多实例部署时极易导致重复处理。
- 如果你有 3 个 Quarkus 实例都
SUBSCRIBE order-events，一条PUBLISH会触发 3 次相同业务逻辑 - 没有内置的“竞争消费者”机制，需自行加分布式锁（如用
SET key val NX EX 30）或改用 Redis Stream - 若只是做配置刷新、服务心跳等通知类场景，广播反而是优势；但涉及状态变更（如库存扣减）必须规避
真正难的不是怎么连上 Redis，而是怎么让订阅在故障、扩缩容、升级过程中持续有效且语义可控——这需要把连接生命周期、重试策略、业务幂等三者绑在一起设计，缺一不可。
