如何通过Redis实现微服务架构中的轻量级事件通知与发布订阅机制？

本文共计1099个文字，预计阅读时间需要5分钟。

不能。它不是为可靠性设计，断连就丢失消息，没有持久化、无ACK、不支持重试。如果需要至少一次或至多一次语义，Redis Pub/Sub不应该是首选——它更适合实时性高、丢失也不关键的告知，例如用户在线状态刷新、控制台日志广播。

常见错误现象：Subscriber 进程重启后收不到断连期间的消息；多个 Subscriber 订阅同一频道，每条消息被全部收到（广播语义，不是队列分发）；高并发发布时出现延迟毛刺。

• 使用场景：配置热更新通知、服务健康心跳广播、开发环境调试事件透出
• 不适用场景：订单创建后扣库存、支付成功后发券、任何需要消息不丢失的业务链路
• 性能影响：发布端 PUBLISH 是 O(N) 复杂度（N = 当前订阅该频道的客户端数），频道订阅过多会拖慢整个 Redis 实例的响应

如何避免 SUBSCRIBE 后收不到消息？

根本原因不是命令写错了，而是连接生命周期没管好。Redis 的 SUBSCRIBE 会让连接进入“订阅模式”，此后只能执行 SUBSCRIBE/UNSUBSCRIBE/PSUBSCRIBE/PUNSUBSCRIBE，其他命令（比如 GET 或 SET）会直接报错 ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / QUIT allowed in this context。