聊聊Kafka消息保留策略：时长和大小怎么配，帮你省存储又保性能

在Kafka集群当中，倘若管理欠缺妥善的状况，那么在数周以前老旧的消息，以及在数月以前就已陈旧的消息，就会不间断地占据数量繁多的磁盘空间，如此一来，这不仅会让存储成本出现增加的情况，还大概会导致新数据的处理速度遭受拖慢的结果。

基于时间的保留策略

有一种在Kafka配置里极为常见的办法，是依据时长作数据清理，其中log.retention.hours参数作用关键，其默认数值为168小时即一周的时长，指超过此一时长的日志段会被自动删除，要是你的业务系统审计有数据需保留一个月的要求，那么可将此参数值设为720小时。

通过 Kafka 命令行工具，利用具体此类 '--alter --config retention.ms=2592000000' 命令，针对单个主题可开展更为精细的控制，特定主题的保留时间能被设定为 30 天，此策略干脆又简单，对于合规性要求清晰明确且数据价值随时间衰减之场景十分适用。 需特别注意的是，上述操作针对的只为单个主题，不是多个主题，并且此策略十分适用于合规性要求清晰明确、数据价值会随时间而衰减的场景。再来讲，利用这类命令针对特定的单个主题，借助 Kafka 命令行工具是能够相应开展更为精细控制的，可将其保留时间设定为 30 天，其策略干脆还简单。

基于大小的保留策略

kafka-topics.sh --create --topic your_topic_name --bootstrap-server your_kafka_broker --config retention.ms=86400000

倘若硬盘存储空间成为最为关键的限制要素之时，便可依照日志的总体规模去设定对应策略，其核心参数是log.retention.bytes，此参数明晰了在分区日志把陈旧数据删除之前所能够扩充到的最大字节数量，比如，你可以规定某一主题的分区日志总的大小不能超过100GB 。

kafka-configs.sh --alter --entity-type topics --entity-name your_topic_name --add-config retention.ms=172800000 --bootstrap-server your_kafka_broker

当所有日志段文件的总体大小超出该阈值之时，Kafka会从最旧的段开始进行删除操作，持续到总体大小低于限定范围。这种情况在处理大量实时数据流的场景中非常有实用价值，能保证数据量不无节制地膨胀，有效控制存储硬件的成本投入额度。

组合使用两种策略

在实际生产状况之中，时间跟大小策略往往会被整合起来予以使用，你能够同时前来设置 log.retention.hours 以及 log.retention.bytes，Kafka 的相关逻辑展现出“或”的关系，只要达成其中任何一个条件，老旧的消息就能够被清理去除。

有这么一种情况，对于某个主题的配置而言，其保留时长是7天或者最大容量为500GB哪怕数据总量还没达到500GB。可是有部分消息已经存放了8天，在这种状况里这一部分消息就会被删除。相反，要是数据出现激增，3天内达到了500GB，这样系统同样会触发清理操作，并且不会等时间到设定的期限。

log.retention.hours=168  # 设置默认的消息保留时长为 168 小时（7 天）

配置管理的具体操作

有一种极具潜力的途径，是通过动态灵活地改变设置而实现符合标准的调整，此途径在既定的主题关联范畴内，借助特定的可用资源，从而被广泛认可，是值得推荐的做法。采用 kafka-configs.sh 工具，联合 --alter 命令并经过精心验证，这是一种有效方式，能在集群正常运作时达到无负面影响的调整效果。例如，执行这样一条命令，这条命令是 bin/kafka-configs.sh --bootstrap - server localhost:9092 --entity - type topics --entity - name user - behavior，通过执行 '--alter --add - config' 的操作，将'retention.ms = 604800000' 这个配置输入进去，最终达成这样一个结果，这个结果是把 “user - behavior” 主题的保留耗时予以改变，使其成为7日持续时长 。

log.retention.ms=604800000  # 设置保留时长为 7 天（604800000 毫秒）

论新建主题，你可于创建命令之中直接指定参数，也就是：--create --config retention.ms=86400000 。若未对特定主题作配置，那 broker 端的 server.properties 文件里的全局默认值就会起作用，如此便简化了集群的初始管理工作。

相关的日志段管理

log.retention.bytes=1073741824  # 设置保留大小为 1 GB

消息保留策略可得以有效施行，是借助底层的日志段管理机制，log.segment.bytes参数对单个日志段文件尺寸上限予以了界定，其默认数值为1GB，当段文件达至这一规模之际，Kafka会滚动式地去打造一个新段。

另外存在一个参数，它被叫做 log.roll.hours，这个参数用于对时间滚动进行控制，它的默认设置是 7 天。即便当下的段文件还没有写满，一旦逾越了这个时间范畴，就会产生新段。将旧消息封闭于已经完成的日志段之中，是高效开展删除操作的必要前提，这是因为 Kafka 是以段作为单元来实施删除的。

设计策略的考量因素

log.retention.check.interval.ms=300000  # 每 5 分钟检查一次

当着手制定策略之时，首先要对业务需要以及数据价值予以考量，鉴于监管规定，金融交易所产生的数据或许需留存数年，然而物联网设备的实时态数据有可能在几小时之后就失去了价值，务必要清晰明确数据的生命周期，权衡合规、审计以及分析等方面的需求。

需要针对存储资源以及成本展开评估，为全部数据设定超长的保留时间会快速导致磁盘被用光，建议借助诸如磁盘使用率、消息流入速率这样的监控指标，定期评估策略的有效性，并且依据业务的变化进行调整，从而避免存储成为性能瓶颈所在之处。

实际工作之时，究竟是凭借怎样的方式，依照业务场景去判定具备适当性的Kafka所发消息应当保留的时长呢？热烈欢迎诸位挑选恰当论坛区域进行参与并阐释，分享自身积累专业知识运用历程以及所遭遇到的艰难问题等各类情形。