最近有幸公司参与kafka消息压缩，背景是日志消息量比较大。kafka版本2.4.1
一、确认压缩算法
根据场景不同选择不同。如果是带宽敏感患者推荐高压缩比的zstd，如果是cpu敏感患者推荐lz4
lz4和zstd底层都使用的是lz77算法，具体实现逻辑不同，根据我们现有日志消息计算最高压缩比。
最终结合我们生产环境最终是确认了使用lz4压缩算法。
二、压缩相关的参数
除了这几个基本的参数外，还需要相应的调整kafka的参数。
| 参数 | 作用范围 | 描述 | 默认值 | 关键依赖关系 | 场景/注意事项 |
|---|---|---|---|---|---|
message.max.bytes | Broker | Broker 允许接收的单个消息最大大小（含消息头、键、值）。 | 1048588 (1MB) | 生产者需设置 max.request.size ≤ 此值；消费者需设置 max.partition.fetch.bytes ≥ 此值 | 若消息超过此值，生产者会被 Broker 拒绝。需与生产者和消费者参数协同配置。 |
replica.fetch.max.bytes | 副本同步（Broker） | 副本从 Leader 分区单次拉取数据的最大字节数。 | 1048576 (1MB) | 必须 ≥ message.max.bytes，否则副本无法同步大消息 | 若设置过小，可能导致副本频繁掉出 ISR 列表。 |
fetch.message.max.bytes | 消费者（旧版本） | 已弃用，替代参数为 max.partition.fetch.bytes。 | 旧版本默认同 max.partition.fetch.bytes | 无（建议使用新参数） | 旧版本兼容性参数，新版本无需关注。 |
max.partition.fetch.bytes | 消费者 | 消费者从单个分区单次拉取数据的最大字节数。 | 1048576 (1MB) | 必须 ≥ message.max.bytes，否则无法消费大消息 | 若分区中某条消息大小超过此值，消费者会抛出异常。 |
num.replica.fetchers | 副本同步（Broker） | Broker 用于副本同步的线程数。增加此值可提升副本同步并行度。 | 1 | 无直接依赖，但需根据集群负载调整 | 分区数多或吞吐量高时，增大此值可加速副本同步。 |
replica.lag.time.max.ms | 副本同步（Broker） | 副本若在此时间内未向 Leader 同步数据，则被标记为不同步（移出 ISR）。 | 30000 (30秒) | 无直接依赖 | 设置过短可能导致副本频繁移出 ISR；过长可能容忍滞后副本（影响可靠性）。 |
接着就是根据prometheus图 不断调整参数找到最适合的参数
)
