Pub/Sub缓冲区超限断连主因是client-output-buffer-limit pubsub配置不当，而非内存不足；其消息不计入used_memory但真实占用物理内存，需按消费能力调优硬限、软限及超时时间，并强制启用maxmemory防OOM。
Pub/Sub 缓冲区超限导致断连，不是内存不够而是配置没对
Redis Pub/Sub 消息不进键空间，used_memory里完全看不到它——但每个订阅连接都独占一块输出缓冲区，这块内存真实存在、不被 maxmemory 管控，却会因堆积触发强制断连。现象通常是客户端突然失联，日志里只有 Client closed connection due to output buffer limit reached，而不是熟悉的 OOM command not allowed when used memory > 'maxmemory'。
关键参数是 client-output-buffer-limit pubsub，默认值 32mb 8mb 60 表示：硬限 32MB（超即断）、软限 8MB 持续满 60 秒也断。生产环境必须按实际消费能力调优：
- WebSocket 广播场景下，后端实例短暂宕机时，缓冲区会指数级堆积，建议软限设为
16mb 60或更高，避免抖动引发雪崩 - 不要盲目调大硬限（如设成
512mb），这部分内存不计入used_memory，不会触发淘汰策略，但会真实吃掉系统物理内存，最终 OOM 杀进程 - 若用哨兵或集群，需确保所有节点统一配置该参数，否则部分节点先断连会造成广播不一致
没配 maxmemory 的 Redis 实例，Pub/Sub 更容易出问题
很多人以为 Pub/Sub 不占 used_memory 就不用管 maxmemory，这是危险误区。没设 maxmemory 会导致两个隐性风险：
-
BGSAVE或AOF rewrite时 fork 子进程失败——因为系统无法预估内存峰值，fork 失败直接中断持久化，主从同步卡住，间接让订阅服务在故障转移中不可用 - 当缓冲区膨胀 + RDB/AOF 同时写盘，物理内存压力叠加，而 Redis 完全无感知，直到 OS 杀掉进程
- 必须显式设置
maxmemory（例如2gb），并搭配maxmemory-policy volatile-lru等策略，让 Redis 在内存紧张时至少能主动回收过期 key，给缓冲区留出喘息空间
Spring Data Redis 的 RedisMessageListenerContainer 默认不保活
Java 应用里用 RedisMessageListenerContainer 订阅频道，看似封装了连接管理，但它默认不做心跳保活、不重连、不处理网络闪断。一旦 Redis 重启或网络抖动，监听器就静默失效，后续消息全部丢失。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须手动增强：
- 设置
setSubscriptionExecutor和setTaskExecutor，避免单线程阻塞导致消息积压 - 启用
setPhase和setAutoStartup(true)，确保容器随 Spring 上下文启动 - 监听
ConnectionFailureEvent或捕获JedisConnectionException，触发手动redisContainer.start()重连 - 不要依赖
MessageListener的单次回调——它不提供 ACK，也不保证顺序，高可靠场景需额外加 DB 落库 + 补偿任务
集群模式下 Pub/Sub 不能跨槽位，但也不是完全不能用
Redis Cluster 对 Pub/Sub 做了妥协：消息只在接收命令的节点本地广播，不会自动转发到其他分片。这意味着如果客户端连的是节点 A，而发布者连的是节点 B，订阅者收不到消息——除非所有客户端都连同一个节点，或使用 --cluster-yes 强制路由。
实际可用方案只有两种：
- 把 Pub/Sub 部署在独立的非集群 Redis 实例上（推荐），专用于广播类低可靠性需求，避开分片复杂度
- 若必须复用集群，所有发布/订阅操作都通过
redis-cli -c或支持集群模式的客户端（如 Lettuce），并确保PUBLISH命令带上{channel}hash tag（如PUBLISH {news}:alert "down"）强制落到同一槽位 - 注意：Cluster 模式下
SUBSCRIBE返回的订阅数是本地节点统计，不代表全局真实在线数，监控时别被误导
真正难的不是让 Pub/Sub 跑起来，而是让它在流量高峰、节点故障、网络分区时不 silently fail。缓冲区配置、maxmemory 强制启用、客户端保活机制、以及是否该把它和集群混用——这四点漏掉任何一环，稳定性都会打折扣。
