持久化Kafka Topic无限期存储的性能相关配置咨询

注意：你当前配置的cleanup.policy: compact为压缩策略，仅会保留每个消息Key的最新版本，同Key的历史版本消息仍会被清理。如果你需要保留全量历史消息（含同Key所有历史版本），请将cleanup.policy调整为delete，配合retention.ms=-1、retention.bytes=-1才能实现真正的消息永不失效。

影响无限期持久化场景性能的核心配置项 #

日志段相关配置 #

• segment.bytes：你当前设置的1G（1073741824）属于通用合理值。如果Topic单分区日写入量超过5G，可以适当调大到2-5G，减少日志段滚动频率，降低文件句柄开销；如果单分区日写入量小于1G，建议调小到256M-512M，避免冷数据日志段长时间不关闭，刷盘滞后。
• segment.ms：未显式配置时默认值为7天，含义是日志段即使未达到大小上限，到指定时间也会自动滚动关闭。无限期保留场景如果要减少文件数量，可以调大到30-90天，需要注意的是调大后如果发生Broker宕机，未关闭的日志段恢复时间会对应变长。
• preallocate：你当前设置为true是合理配置，会提前预分配日志段的磁盘空间，避免写入时触发空间分配的额外开销，机械盘环境下对写入性能提升非常明显，建议保持开启。

清理策略相关配置 #

若使用compact压缩策略（仅保留每个Key最新版本）

• min.cleanable.dirty.ratio：你当前设置为0.5，含义是脏数据（未压缩数据）占比达到50%才触发压缩操作。如果磁盘IO资源富余可以调低到0.2-0.3，减少单次压缩处理的数据量，避免高峰时段IO突增；如果磁盘IO紧张可以保持0.5或调高到0.7，降低压缩触发频率。
• min.compaction.lag.ms：默认值为0，含义是消息写入后立刻可以被压缩。建议设置为86400000（1天），避免刚写入的热数据被压缩，影响近期消费的性能。
• delete.retention.ms：默认值为86400000（1天），是压缩策略下墓碑消息（标记为删除的Key）的保留时间。需要保证这个值大于下游消费者的最长落后时间，避免墓碑消息提前被清理，下游消费端收不到删除通知。

若使用delete删除策略（保留全量历史消息）

仅需保证retention.ms=-1、retention.bytes=-1即可，不会触发任何自动删除操作，无需额外配置压缩相关参数。

Broker侧关联配置 #

• 建议将无限期保留的Topic数据单独挂载到大容量、高性能的磁盘分区，避免和短保留周期的Topic争抢IO资源。
• 适当调大num.replica.fetchers参数（默认值为1），提升副本同步速度，避免大存量Topic的副本同步落后太多。
• 不要设置过小的log.flush.interval.messages、log.flush.interval.ms刷盘阈值，建议使用操作系统默认的页面缓存刷盘策略，避免频繁刷盘导致IO占用过高，拖累写入性能。

Strimzi配置参考示例 #

全量历史消息永不删除配置 #

retention.ms: -1
retention.bytes: -1
segment.bytes: 1073741824 # 可根据单分区写入量调整
segment.ms: 2592000000 # 30天，可根据需求调整
cleanup.policy: delete
preallocate: true

按Key保留最新版本配置 #

retention.ms: -1
retention.bytes: -1
segment.bytes: 1073741824
segment.ms: 2592000000 # 30天
cleanup.policy: compact
min.cleanable.dirty.ratio: 0.5
min.compaction.lag.ms: 86400000 # 消息写入后1天内不允许压缩
delete.retention.ms: 172800000 # 墓碑消息保留2天
preallocate: true

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