Redis的发布订阅模型是什么，有哪些缺点？
Redis 发布订阅模型概述
Redis 发布订阅（Pub/Sub）是一种消息广播模式，核心角色包括：
- 发布者（Publisher）：向指定频道（Channel）发送消息。
- 频道（Channel）：消息的逻辑载体，用于区分不同主题的消息。
- 订阅者（Subscriber）：订阅一个或多个频道，接收该频道的所有消息。
模型示意图（文字描述）：
┌───────────┐│ Publisher │└─────┬───────┘│ 发布消息▼┌───────────────┐│ Channel: news │└───────────────┘│ 广播消息▼
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Subscriber1 │ │ Subscriber2 │ │ Subscriber3 │
└───────────┘ └───────────┘ └───────────┘
Redis 发布订阅的缺点
- 消息无持久化：消息发送后若订阅者离线，离线期间的消息会完全丢失（Redis 5.0 后支持
Consumer Group部分解决此问题，但原生 Pub/Sub 仍不支持）1； - 无法回溯历史消息：订阅者只能接收订阅后的新消息，无法获取历史消息；
- 无消息确认机制：发布者无法知道订阅者是否成功接收消息；
- 性能瓶颈：当频道数量或消息量极大时，可能导致网络或内存压力。
Java 代码实现案例（使用 Jedis 客户端）
1. 添加 Maven 依赖
<dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>4.4.3</version> <!-- 最新稳定版 -->
</dependency>
2. 订阅者实现（监听频道消息）
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPubSub;public class RedisSubscriber {public static void main(String[] args) {// 连接 Redis（默认 localhost:6379）try (Jedis jedis = new Jedis("localhost", 6379)) {// 创建订阅者实例，监听 "news" 频道JedisPubSub pubSub = new JedisPubSub() {@Overridepublic void onMessage(String channel, String message) {System.out.printf("收到频道 [%s] 的消息: %s%n", channel, message);}};// 启动订阅（阻塞当前线程）System.out.println("开始监听频道 news...");jedis.subscribe(pubSub, "news");}}
}
3. 发布者实现（向频道发送消息）
import redis.clients.jedis.Jedis;public class RedisPublisher {public static void main(String[] args) {try (Jedis jedis = new Jedis("localhost", 6379)) {// 向 "news" 频道发送消息jedis.publish("news", "今日天气：晴，25℃");jedis.publish("news", "Redis 发布订阅示例完成！");System.out.println("消息发送完成");}}
}
运行说明
- 确保本地 Redis 服务已启动（默认端口 6379）；
- 先运行
RedisSubscriber（会阻塞等待消息）； - 再运行
RedisPublisher，订阅者控制台会显示接收的消息。
注意：若 Redis 有密码，需在
Jedis构造函数后添加jedis.auth("密码")；若 Redis 部署在远程服务器，需修改Jedis构造函数的主机地址和端口。
场景推荐
Redis 发布订阅（Pub/Sub）模型适合以下对实时性要求高、允许消息丢失、无需历史回溯的场景：
1. 实时聊天/群组消息
- 场景描述：在线聊天应用的群组功能（如微信群聊），用户在线时可即时接收消息。
- 适配原因：Pub/Sub 的广播特性可快速将消息推送给所有在线群成员；离线用户的消息可通过额外存储（如数据库）补充，不依赖 Pub/Sub 本身的持久化。
2. 实时通知/推送
- 场景描述：新闻客户端的“热点推送”、电商的“促销提醒”等。
- 适配原因：消息需快速触达在线用户（如新闻时效性强），离线用户错过的消息可通过“红点提醒+历史页”补偿，无需 Pub/Sub 存储。
3. 分布式系统事件广播
- 场景描述：微服务架构中，某个服务触发事件（如“库存更新”），需通知所有依赖该事件的其他服务（如订单、物流服务）。
- 适配原因：轻量级的 Pub/Sub 可快速广播事件，避免服务间直接调用的耦合；若需保证可靠性，可结合数据库记录事件状态。
4. 实时监控与告警
- 场景描述：服务器集群的 CPU/内存监控，当指标超限时立即通知运维系统。
- 适配原因：监控数据需实时展示（如仪表盘），短暂离线的监控端错过的少量数据可通过“最近 N 分钟平均值”补充，不影响整体监控逻辑。
不推荐场景
- 需消息可靠传递（如支付通知）：Pub/Sub 无确认机制，消息可能因订阅者离线丢失。
- 需历史消息回溯（如客服聊天记录）：订阅者只能接收订阅后的新消息，无法获取历史。
- 高吞吐量消息队列（如日志收集）：Pub/Sub 无消息缓冲，大量消息可能压垮订阅者。