Redis Pub/Sub 不支持自动消息压缩，因PUBLISH内容直写输出缓冲区，绕过LZF等内存压缩逻辑；需客户端自行压缩/解压，并统一算法；高频短消息推荐LZ4/Snappy；长期应改用Stream替代。
Redis 的 Pub/Sub 本身不支持消息压缩传输，PUBLISH 和 SUBSCRIBE 协议层没有任何内置压缩机制，所有消息都以原始字节流形式在网络上传输。想减少带宽占用，必须在客户端自己动手压缩/解压。
Pub/Sub 消息为什么不能靠 Redis 自动压缩
Redis 的 LZF 压缩仅作用于内存存储结构（如 ziplist、hash 的内部编码）和 RDB/AOF 持久化文件，PUBLISH 发送的内容不会经过任何压缩路径 —— 它直接写入订阅者的输出缓冲区，绕过所有存储编码逻辑。即使你存的是一个被 LZF 压缩过的 SET 值，用 PUBLISH 推出去的仍是明文字符串。
常见错误现象：INFO memory 显示 used_memory_human 很小，但网络监控发现 Pub/Sub 流量巨大；或订阅端收到乱码，其实是没做解压就当 UTF-8 解析了。
- Redis 不会对
PUBLISHpayload 做任何预处理，包括 base64 编码、压缩、序列化 - 压缩后的二进制数据可能含
\x00或非 ASCII 字节，直接传给PUBLISH没问题，但某些客户端库（如旧版 redis-py）默认按字符串处理，会截断或报错 - 发布者和订阅者必须约定同一种压缩算法和解包方式，否则无法互通
客户端压缩的实操要点：选算法 + 控制边界
推荐优先用 LZ4 或 Snappy，不是因为压缩率高，而是它们解压快、CPU 友好、且对短消息（
关键参数差异：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
LZ4：压缩比中等（约 2–3×），解压速度可达 500MB/s+，适合高频小消息 -
Snappy：压缩比略低于 LZ4，但更轻量，Google 内部大量用于 RPC 场景 -
zlib：压缩比高（4–5×），但单核压缩耗时是 LZ4 的 5 倍以上，慎用于实时通知类场景
示例（Python + redis-py）：
import lz4.frame
import redis
<p>r = redis.Redis()
msg = b'{"event":"order_created","id":"abc123","items":[]}'
compressed = lz4.frame.compress(msg) # 注意：返回 bytes，不是 str
r.publish('events', compressed) # 直接发 bytes订阅端必须反向解压：
def handle_message(message):
try:
raw = message['data']
decompressed = lz4.frame.decompress(raw) # 不能跳过这步
print(decompressed.decode('utf-8'))
except Exception as e:
print("解压失败:", e)压缩带来的隐性成本和兼容性坑
压缩不是白来的。容易被忽略的点：
- 消息体变小了，但每个
PUBLISH调用多了 1–2ms CPU 开销；若每秒发万级消息，得评估 CPU 是否成为瓶颈 - 不同语言客户端要统一压缩逻辑：Go 用
lz4库，Java 用net.jpountz.lz4，Python 用lz4.frame，版本不一致可能导致解压失败 - 调试困难：Redis CLI
redis-cli --csv SUBSCRIBE events看到的是乱码，得先xxd或写脚本解压才能读内容 - 如果消息里混有未压缩的旧数据（比如历史遗留服务还在直发 JSON），订阅端必须能区分并兼容两种格式，建议加个 magic byte 或头部 flag
真正需要压缩 Pub/Sub 的时候，往往说明消息体已经偏大（>1KB）或频次很高。这时候更该回头看看：是不是该换 Stream？它原生支持 XADD 的 MAXLEN 和消费者组，还能落盘，比纯内存的 Pub/Sub 更可靠。压缩只是权宜之计，不是架构解法。
