Redis Pub/Sub 消息体超100KB必然引发网络抖动，因单线程串行处理PUBLISH导致主线程卡死，进而造成命令排队、连接重试、从节点断连、连接雪崩等连锁反应。
Redis Pub/Sub 消息体超 100KB 就会引发网络抖动，这不是“可能”，而是单线程模型下的必然连锁反应。
为什么大 Payload 会让 Redis 主线程卡死
Redis 处理 PUBLISH 命令时完全不校验大小，所有动作都在主线程串行执行：JSON 序列化 → 内存拷贝 → 遍历每个订阅者 → 分别写入各自 client output buffer → 发送。一个 2MB 的消息，可能让主线程停顿 200ms+，期间所有命令（GET、SET、PING）全部排队。
现象上表现为：redis-cli --stat 中 pubsub_channels 内存持续上涨，INFO memory 的 used_memory_dataset 异常跳升；监控里 RT 突刺、RedisCommandTimeoutException 暴增——这其实是主线程被占满后，其他请求被迫等待超时的结果。
- 别信
proto-max-bulk-len默认 512MB，它只管协议解析层，不拦PUBLISH逻辑 - 真正安全上限是
1024 * 100字节（100KB），必须在序列化后立刻检查len(data) - 中文 JSON 序列化后体积常翻倍，原始字符串 50KB 可能膨胀到 150KB，不能靠预估
为什么主线程卡死会传导为网络抖动
主线程卡住 ≠ 网络断开，但会直接恶化网络表现：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端
PING超时未响应，触发连接重试或断连，TCP 连接数剧烈波动 - 从节点心跳
REPLCONF ACK延迟堆积，主节点误判为网络故障，反复触发repl-timeout断连与重同步 - 大量未发送完的 output buffer 占用内存，触发
client-output-buffer-limit限流，强制踢掉慢订阅者，造成连接雪崩 - Lettuce 或 Jedis 的连接池因响应延迟积压，新建连接激增，加剧 NAT 网关/SLB 的连接跟踪表压力，诱发空闲连接被静默回收
订阅端长度校验必须在反序列化之前
很多团队在 Python 里写 json.loads(msg["data"]) 后才判断长度，这已经晚了：大对象早已分配，GC 压力陡增，还可能 OOM。正确姿势是禁用自动解码，拿到原始字节后立刻测长：
- Python
redis-py：用redis.Redis(decode_responses=False)，再判断len(msg.get("data", b"")) > 102400 - Node.js
ioredis：监听messageBuffer事件而非message，避免 UTF-8 解码开销 - Go
redigo：用c.Receive()得到redis.Message，直接读msg.Data字节切片
拆分消息到多个频道反而更危险
把大消息切片发到 order:12345:part1、order:12345:part2 看似合理，实则放大风险：
- 每个
PUBLISH仍需完整走一遍主线程流程，卡顿次数翻倍 - 订阅端要维护状态、保序拼接、超时重试，出错概率指数级上升
- 无法规避单条 PUBLISH 的阻塞本质，只是把问题从“一次卡死”变成“多次卡死”
- 真正可行的是业务层放弃传原始数据，改用「轻量通知 + 按需拉取」：
PUBLISH order:updated '{"id":"12345","ts":1716645720}'，收到后再异步查GET order:12345或调 API
最容易被忽略的一点：PUBLISH 前的长度检查，必须在最终序列化之后做。那几毫秒的 len() 调用省不得，否则你永远不知道发出去的到底是 99KB 还是 210KB。
