Redis Pub/Sub是即发即弃的广播机制，非严格消息队列；适用于实时通知类场景，如状态广播、配置变更等，不保证消息持久化与可达性。

Redis Pub/Sub 本身不是严格意义上的消息队列，而是一种“即发即弃”的广播机制。但它能快速、低延迟地实现简易消息队列功能，特别适合对消息可靠性要求不高、强调实时通知的场景，比如服务状态广播、在线用户事件推送、配置变更通知等。

核心命令要会用

只需三个命令就能跑通基本流程：

• SUBSCRIBE channel：订阅频道，客户端进入阻塞监听状态，只响应 Pub/Sub 相关命令
• PUBLISH channel message：向频道发消息，返回值是收到消息的订阅者数量（0 表示无人在线）
• UNSUBSCRIBE [channel]：取消订阅；不带参数则退订所有频道

例如：
终端 A 执行 SUBSCRIBE order:notify → 开始等待订单通知；
终端 B 执行 PUBLISH order:notify "order_12345 created" → A 立刻收到消息。

支持一对多和模式匹配

一个发布动作可同时触达多个订阅者，天然适合广播类需求：

• 订阅多个频道：SUBSCRIBE log:error log:warn
• 用通配符批量订阅：PSUBSCRIBE user:* 可接收 user:1001、user:1002 等所有匹配频道的消息
• 对应取消模式订阅：PUNSUBSCRIBE user:*

这种灵活性让前端按用户 ID 分频道、后端按业务域分主题变得很自然。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

注意它“不存消息”的本质

Pub/Sub 没有消息堆积能力，这是和 Kafka/RabbitMQ 的关键区别：

• 订阅者必须在线，离线期间发布的消息完全丢失
• 消息不落盘、不持久化、不重试、不确认
• 没有消费组、没有偏移量、无法回溯历史

所以它不适合订单处理、支付回调这类需要 100% 投递保障的链路。若需容错，得额外结合 List 或 Stream 实现“先存后发”。

简单但实用的运维检查

上线前建议用两个命令确认状态：

• PUBSUB CHANNELS：列出当前有至少一个订阅者的活跃频道
• PUBSUB NUMSUB order:notify：查指定频道当前有多少个活跃订阅者（便于监控服务是否掉线）

这些信息能帮你快速判断消息是否可能被漏收，尤其在灰度发布或服务重启时很有用。