client-output-buffer-limit配置不当会导致从节点断连；Pub/Sub无ACK机制，不适用于关键业务；应使用Redis Streams替代。
client-output-buffer-limit 配置不当会导致从节点断连
Redis 发布订阅本身不涉及主从复制，但实际生产中常与主从架构共存；当订阅者是 Redis 从节点（比如用 redis-cli --slave 模拟监听），或业务服务通过长连接订阅时，client-output-buffer-limit 的限制会直接影响消息接收稳定性。
默认配置 client-output-buffer-limit normal 0 0 0 对普通客户端不限制，但对 slave 和 pubsub 类型客户端有独立策略。若未显式配置 pubsub 行，它会继承 normal 值，而 pubsub 连接在高吞吐下极易堆积未消费消息——缓冲区满即被强制断开，且不会重试。
-
client-output-buffer-limit pubsub 32mb 8mb 60是较稳妥的起点：硬上限 32MB，软上限 8MB 持续 60 秒即断连 - 若订阅端处理延迟波动大（如依赖下游 HTTP 调用），可适当放宽软上限，但避免设为
0，否则内存可能被单个慢订阅者耗尽 - 该参数需在所有 Redis 实例（含哨兵、集群节点）的
redis.conf中统一配置，热加载不生效，必须重启
publish 命令性能瓶颈不在 Redis 本身，而在序列化和网络层
实测表明，在千级 QPS 下，PUBLISH 自身耗时通常低于 0.1ms，真正拖慢的是序列化开销和 TCP 包大小。尤其当消息体含 JSON 字符串、嵌套结构或未压缩二进制时，带宽和反序列化成本会指数级上升。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 避免直接
PUBLISH channel {"user_id":123,"action":"login"}，改用 Protobuf 或 MessagePack 序列化，体积减少 40%~60% - 单条消息建议控制在 10KB 以内；超大消息不仅增加网络延迟，还会阻塞同一连接上的其他命令（Redis 单线程模型）
- 批量发布不要拼接多条
PUBLISH命令发往同一连接——Redis 不支持原子性批量 pub，应由客户端合并后分频道发送
频道命名混乱会引发内存泄漏和运维盲区
Redis 不会自动清理空频道，SUBSCRIBE foo:bar:user_123 这类带动态 ID 的频道名，只要有一个客户端曾订阅过，该频道就一直存在。长期运行后，PUBSUB CHANNELS * 可能返回数万无效频道，影响命令响应速度，也掩盖真实热点频道。
- 强制约定频道层级：如
event:order:created、metric:cpu:high，禁止在频道名中嵌入业务 ID 或时间戳 - 高频低价值消息（如心跳、埋点）单独走轻量级频道，避免挤占核心业务频道的输出缓冲区
- 定期用
PUBSUB NUMSUB扫描长期无订阅者的频道，脚本化清理（注意：删除频道只能靠无人订阅后自然消失，无法主动删）
没有 ACK 机制的发布订阅不适合关键业务消息
Redis Pub/Sub 是“发了就算”，不保证送达、不记录历史、不支持重放。哪怕订阅者网络抖动 1 秒，期间所有消息永久丢失。这点常被误认为“够快所以够可靠”，实际恰恰相反。
- 订单状态变更、支付结果通知等必须至少一次送达的场景，别用
PUBLISH/SUBSCRIBE，改用 Redis Streams +XADD/XREADGROUP，它支持消费者组、ACK、pending 列表和消息重播 - 若坚持用 Pub/Sub，必须在客户端实现应用层补偿：例如发布前先写 DB 记录消息 ID，订阅端消费后回调确认，定时任务扫描未确认消息并重推
- 监控上重点关注
instantaneous_ops_per_sec和rejected_connections，前者突增可能意味着下游消费卡住，后者说明新订阅被拒绝——往往是maxclients或缓冲区已满
