RabbitMQ消息压缩必须由客户端实现，因Broker不解析payload且无内置压缩功能；推荐LZ4算法平衡速度与压缩比，小于1KB消息不宜压缩；需通过headers传递压缩标识并兼容未压缩消息。
在 RabbitMQ 中实现消息体压缩传输，核心思路是不在 Broker 层做压缩，而是在生产者发送前压缩、消费者接收后解压。RabbitMQ 本身不内置消息压缩功能，也不解析 payload 内容，所以必须由应用层控制——这反而更灵活、可控，也避免了 Broker 成为 CPU 瓶颈。
为什么必须客户端侧压缩
RabbitMQ 只负责路由和存储字节流，对消息内容完全透明。它不识别 JSON、Protobuf 或任何格式，自然也不会自动压缩。强行在服务端加压缩模块会引入额外延迟、破坏协议兼容性，且无法适配不同业务的数据特征（比如小消息压缩后可能反而变大）。
选对算法：兼顾压缩比与 CPU 开销
常见压缩算法在 RabbitMQ 场景中的适用性差异明显：
- GZIP：压缩比高（通常 60%~80%），适合文本类消息（JSON 日志、XML 配置），但 CPU 开销中等偏高，适合吞吐量不高但带宽紧张的场景；
- Snappy：压缩比中等（40%~60%），压缩/解压极快，CPU 占用低，适合高频、实时性要求高的物联网或事件流场景；
- LZ4：与 Snappy 类似，解压速度更快，部分语言生态支持更好（如 Java 的 Netty、Python 的 lz4 包），是当前推荐的平衡之选。
注意：小于 1KB 的消息一般不建议压缩——压缩后体积可能不变甚至增大，还白耗 CPU。
生产者压缩 + 消费者解压（Python 示例）
关键是在发送前把 payload 压缩成 bytes，并设置自定义 header 标明压缩方式，便于消费者识别：
- 生产者示例（使用 lz4）：
import lz4.frame
import pika
message = b'{"sensor_id":"s001","temp":23.5,"ts":1723003200}'
compressed = lz4.frame.compress(message)
connection = pika.BlockingConnection()
channel = connection.channel()
channel.basic_publish(
exchange='', routing_key='data_queue',
body=compressed,
properties=pika.BasicProperties(headers={'compression': 'lz4'})
) - 消费者收到后先读 header，再按对应算法解压：
def callback(ch, method, properties, body):
algo = properties.headers.get('compression')
if algo == 'lz4':
body = lz4.frame.decompress(body)
data = json.loads(body)
# 后续业务处理
几个容易忽略但影响效果的关键点
- 压缩前确认 payload 是 bytes 类型，不是 str；JSON 要先 dumps 再 encode；
- 务必通过 headers 传递压缩标识，不要靠约定位置或固定格式，否则升级扩展困难；
- 消费者需兼容未压缩消息（header 缺失时直接使用原始 body），保证灰度发布平滑；
- 监控压缩前后消息平均体积、CPU 使用率、端到端延迟，避免“压缩后延迟没降反升”的情况。
