使用 Redis Pub/Sub 消息丢失为什么没有报错信息？

Redis Pub/Sub 采用“即发即弃”模式发布者发送消息后立即返回不关心消息是否被成功接收。如果订阅者未在线、网络抖动或缓冲区溢出消息直接丢弃不会触发任何错误回调或异常。因此从发布者视角看永远不会收到“消息丢失”的报错信息。这不是程序 bug而是该模式的设计限制——它不保证交付只保证尽力发送。怎么确认消息真的丢了因为不报错确认丢失只能靠订阅者端的间接证据。唯一可靠的方式是在订阅者端监听reconnect事件并检查断连期间的消息积压情况。但 Redis Pub/Sub 本身不记录历史消息订阅者重新连接后无法获取断连期间的消息。若发现订阅者处理的消息数量少于预期且无报错基本可判定为 Pub/Sub 模式下的消息丢失。也可以直接在订阅者日志中排查是否有大量“client-output-buffer limit”相关的断开日志。当订阅者消费速度慢于发布速度或者网络不稳定导致连接中断时Redis 会强制断开连接并丢弃后续消息。断开动作本身不会通知发布者仅在订阅者端可见。如果不丢消息什么方案更适合若业务不允许丢失任何消息应避免使用 Pub/Sub改用 Redis Stream 或可靠消息队列如 RabbitMQ。Stream 支持消息持久化、消费者组和确认机制可以在断连后重新消费未确认的消息。如果必须使用 Pub/Sub例如对实时性要求极高且允许少量丢失可通过以下方式缓解风险增加订阅者连接数分摊消费压力调大client-output-buffer-limit pubsub 256mb 64mb 60参数给订阅者更充足的缓冲区让订阅者尽快消费消息避免积压。但需要明确这些措施只能缓解无法从根本上保证不丢。改完后看这几个信号调整配置后重点观察两个地方订阅者日志是否仍有“client-output-buffer limit”断连记录。如果明显减少或消失说明缓冲区溢出导致的丢失已缓解。消息计数如果发布者能统计发送数量、订阅者能统计接收数量通过本地计数器或外部时序对比两者差值是否缩小。差值趋近于零说明丢失基本被控制但差值不可能完全消失因为网络闪断等不可预知事件仍可能导致丢失。也可以引入心跳机制订阅者定期向监控系统汇报自身状态如果发现订阅者长时间未汇报可人工介入检查。最后记住一句话用了 Pub/Sub就要接受它可能丢消息的设计。没有报错不是 bug而是特性。在需要可靠交付的场景下更换方案比修补更省心。