Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
Redis发布订阅为什么怕大Key
因为 PUBLISH 命令本身不校验消息体大小，一旦往频道塞入几MB的JSON或二进制数据，会直接卡住主线程——Redis是单线程处理网络IO和命令执行的，大Payload意味着更长的序列化、内存拷贝、广播遍历时间，所有客户端都会感知到延迟飙升，甚至触发超时断连。
这不是“偶尔慢一下”的问题，而是只要有一个订阅者消费慢（比如网络抖动、下游处理阻塞），整个频道的后续消息就会在服务端积压，redis-cli --stat 里能看到 pubsub_channels 对应的内存持续上涨，INFO memory 中 used_memory_dataset 异常增长。
如何在应用层限制Payload大小
最有效的方式是在调用 PUBLISH 前做截断或拒绝，而不是依赖Redis自身——它压根没提供类似 maxmemory-policy 那样的发布级限流。
- Go 示例：用
len(msgBytes) > 1024 * 100（100KB）直接返回错误，不发；若必须传大结构，改走异步任务+消息ID通知 - Python 示例：在封装的
publish()方法里加if len(payload) > 102400: raise ValueError("payload too large") - Java（Lettuce）：用
ByteBuf.readableBytes()检查前再调用publish()，避免序列化后才发现超限
注意：不要只检查原始字符串长度，JSON序列化后可能膨胀（如中文转Unicode），应在序列化完成后再测字节长度。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
订阅端如何避免被大消息拖垮
很多团队只管发不管收，结果一个1MB的消息让Python的 redis-py 订阅线程卡死3秒以上，期间无法响应心跳或新消息。
- 用
redis.Redis(connection_pool=pool, decode_responses=False)禁用自动解码，避免UTF-8解析开销 - 订阅逻辑里对
message["data"]做长度预检：if len(data) > 102400: logger.warning("skip oversized msg"); continue - Node.js 使用
ioredis时，开启enableOfflineQueue: false，防止离线期间消息堆积撑爆内存
关键点：丢弃必须发生在反序列化之前，否则已经分配了大内存对象，GC压力反而更大。
替代方案比硬扛大Key更可靠
发布订阅本质是轻量广播，不是消息队列。真有大Payload需求，该换就换，别硬拗。
- 小文件/配置变更 → 改用
SET key value EX 300+EXPIRE+ 订阅__keyevent@0__:expired事件（需notify-keyspace-events开启） - 业务事件含大附件 → 发布一个精简的
{"event":"order_created","id":"xxx"}，下游按需调HGETALL order:xxx或查DB - 实时日志分发 → 切到 Kafka / Pulsar，它们原生支持消息分片、背压控制和磁盘缓冲
真正容易被忽略的是：Redis的 PUBSUB NUMSUB 返回的只是连接数，不代表活跃消费者——那些挂着但不读 READ 的客户端，照样吃内存、拖慢广播，得靠心跳+超时主动踢掉。
