Kafka从Broker侧压缩切换为生产者端压缩的相关问题咨询

1. 从compression.type=lz4切换为compression.type=producer的注意事项 #

• 先理清资源开销转移逻辑：原配置下Broker会无视生产者的压缩设置，对所有收到的消息强制解压后重新用lz4压缩，CPU消耗集中在Broker端；切到compression.type=producer后Broker不会做任何重压缩操作，直接原样落盘生产者提交的压缩消息，压缩的CPU开销会全部转移到生产者进程，上线前必须压测评估生产者节点的CPU余量，避免压缩占满CPU导致业务发送阻塞。
• 切换操作本身无业务中断风险：该配置是Topic级动态参数，修改后即时生效，不需要重启Broker，切换前写入的lz4格式消息会保留原有压缩格式，新旧消息消费者都可以正常读取，不需要做存量数据迁移。
• 提前对齐参数阈值：原Broker重压缩模式下会自动调整消息批次大小适配本地存储限制，切到生产者压缩后，需要核对生产者端batch.size配置不要超过Topic设置的max.message.bytes、Broker全局的message.max.bytes阈值，否则会出现消息过大被Broker拒收的错误；同时可以适当调大linger.ms攒够批次再压缩，能明显提升压缩率、降低网络传输量。
• 提前确认版本兼容性：如果后续计划使用zstd压缩算法，必须保证集群Broker版本不低于2.1.0，低版本Broker无法识别zstd格式的消息，会直接返回写入错误。
• 监控项同步调整：切换后重点盯三类指标：Broker端的压缩CPU使用率（正常会有明显下降）、生产者端的压缩耗时和发送错误率、消费者端的解压耗时，避免出现端到端延迟突增的问题。

2. 生产者侧更换压缩算法是否需要重处理Topic #

完全不需要重处理Topic，Kafka原生支持同一Topic下混合存储多种压缩格式的消息。

• Kafka的压缩算法元数据是跟着每个消息批次走的，不是和Topic绑定的：每一批消息在发送时，生产者会把当前批次使用的压缩算法标识写在消息批次的头部元数据里，Broker落盘时会完整保留这部分元数据，不会做修改。消费者拉取消息时，直接从当前批次的元数据里读取压缩算法类型，自动匹配对应的解压逻辑即可，哪怕同一个Topic的不同分区、甚至同一个分区里先后存了lz4、zstd、snappy、gzip等不同压缩格式的消息，消费者都能正常解析，不会出现格式不兼容的错误。
• 唯一需要提前校验的是客户端版本：所有读写该Topic的生产者、消费者客户端版本，必须支持你后续切换的压缩算法。比如切换为zstd算法时，所有客户端的Kafka依赖版本需要升级到2.1.0及以上，否则老版本客户端无法识别zstd格式，会抛出解压失败的异常。
• 补充说明：只有当Topic的compression.type配置为固定算法（比如lz4、zstd）时，Broker才会强制把所有写入消息转成对应统一格式落盘；只要配置为producer模式，Broker不会干预落盘消息的压缩格式，混合存储多种压缩算法是官方支持的标准能力，不存在生命周期内必须使用单一压缩算法的限制。

内容的提问来源于stack exchange，提问作者filpa