必须在发送前用json.Marshal获取原始字节长度，再通过AsyncProducer预估压缩后大小；实际压缩比需结合Broker端kafka-dump-log.sh验证，单条预估不等于batch级真实压缩比。
怎么用 sarama 获取原始消息体和压缩后字节长度
压缩比不是 Kafka 客户端直接暴露的指标，得靠你自己在发送前/后分别抓取字节长度。关键点在于：必须在消息真正编码进网络请求前拿到原始内容，再对比 Broker 实际写入日志时的磁盘大小——但后者你没法直接读。所以生产环境常用折中法：用 sarama 的 ProducerMessage + 自定义 Encoder 拦截原始 payload，再通过 config.Producer.Compression 设置（如 sarama.CompressionSnappy）触发压缩，最后用 len(msg.Value.Encode()) 和压缩后实际发出去的 batch 字节数做比对。
注意：msg.Value.Encode() 返回的是未压缩的原始字节；而真正发出去的 batch 大小，需要开启 config.Producer.Return.Successes = true 并监听 Successes() channel，但该 channel 不带 wire size。所以更可行的做法是：在 SendMessage 前，手动调用 sarama.encodeBatch(...)（非公开函数，不推荐），或改用 AsyncProducer + Input() channel，在写入前用 proto.Marshal 或 json.Marshal 预估大小。
- 最稳的实操路径：把消息先
json.Marshal成[]byte，记下len(raw) - 显式设置
config.Producer.Compression = sarama.CompressionZSTD（需 v1.20+ 且 CGO_ENABLED=1） - 用
AsyncProducer，把[]byte封装进&sarama.ProducerMessage{Value: sarama.ByteEncoder(payload)} - 不真发，而是用
sarama.NewSyncProducer的 mock config 测试单条，或本地起 Kafka +kafka-dump-log.sh查 segment 文件实际 size
kafka-go.Reader 为什么没法直接算压缩比
kafka-go.Reader 在读取消息时已自动解压，ReadMessage 返回的 msg.Value 是解压后的原始字节，你永远拿不到 wire 上的压缩包大小。它甚至不暴露底层 RecordBatch 结构。这意味着：想监控线上压缩效果，不能依赖消费端反推。
如果你硬要估算，唯一办法是让生产者打日志：在调用 reader.WriteMessages 前，对每条消息做 len(json.Marshal(v))，再按 topic/partition/offset 记录到 metrics（比如 Prometheus）。但这只反映“应用层序列化后大小”，不等于 Kafka wire 格式压缩比——因为 Kafka 还会把多条消息打包进一个 batch 再统一压缩（batch-level compression），单条预估必然偏高。
立即学习“go语言免费学习笔记（深入）”；
- batch 压缩比 ≠ 单条压缩比：10 条 1KB 消息合起来压缩，可能压到 3KB；单独压每条，可能各剩 800B，总和 8KB
-
kafka-go默认启用MinBytes=1，容易导致小 batch，压缩率差；设成10240可提升压缩效率，但会增加延迟 - 别信
msg.Headers里的"compression"key——那是逻辑标记，不是真实 size
线上压测时怎么验证 ZSTD / LZ4 是否生效
光看客户端配置没用。Broker 必须也开启对应压缩器，且 topic 级参数 compression.type 不能是 producer 以外的值（否则强制覆盖）。验证是否真生效，最直接的方式是查 Broker 日志或用 kafka-dump-log.sh 看 record batch header：
执行：kafka-dump-log.sh --files /tmp/kafka-logs/my-topic-0/00000000000000000000.log --print-data-log | head -20
如果看到 compression.codec: 3（ZSTD）或 2（LZ4），说明压缩已启用。再对比同样数据量下磁盘占用：启用 ZSTD 后，segment 文件体积应比 Snappy 低 20–30%，比 none 低 50%+。
- Broker 配置必须含
compression.type=zstd（全局）或topic级compression.type=zstd - 客户端
sarama版本 ≥ v1.20 且编译时CGO_ENABLED=1，否则 ZSTD 被静默降级为 none - Windows 下若没装 gcc，
saramav1.20+ 会 panic，得切回 v1.19 并放弃 ZSTD -
kafka-go默认不支持 ZSTD，v0.4+ 才加入，需确认你用的是 ≥ v0.4.0
压缩比突降通常意味着什么
不是代码写错了，大概率是数据特征变了。Kafka 压缩对重复字符串、结构化字段（如 JSON key 名）、时间戳序列极其敏感。如果某天压缩比从 4:1 掉到 1.2:1，优先检查：
- 消息体里混入了随机 base64 图片或加密 blob——这类数据几乎不可压缩
- JSON 序列化用了
json.MarshalIndent，多了大量空格换行 - Producer 端开启了
config.Producer.Interceptors，中间加了 UUID 或 traceID 字段，破坏了字段重复性 - Topic 被重建过，新 partition 的
compression.type被重置为uncompressed - Client 误配了
config.Version，导致 Broker 拒绝压缩 batch，回落到 per-message encoding
真正的压缩比监控，得在 Producer 侧埋点：对每个 batch 记录 len(raw_bytes) 和 len(wire_bytes)（后者需 patch sarama 或用 eBPF 抓 socket send），而不是靠消费端猜。这点很容易被忽略，但决定了你能不能快速定位是数据问题还是配置漂移。
