Kafka日志保留多久，不能只按“磁盘还剩多少”决定：业务请求量、消息大小、峰值持续时间和增长速度，决定每天写入多少数据；副本数、压缩效果、分区分布和磁盘预留空间，则决定这些数据最终占用多少服务器容量。保留时间要满足故障排查与业务回溯需求，同时避免磁盘持续逼近满载。
规划时可先把问题拆成两项：期望保留的时间窗口，以及该窗口内实际产生的磁盘数据量。若数据量在保留窗口内超过容量预算，Kafka可能先按容量上限清理旧日志，实际保留时间便会短于设定值。反过来，若按时间清理后磁盘仍有余量，也不代表可以忽略峰值和增长带来的后续压力。
一、先建立负载画像：消息量不等于日志占用量容量估算的起点不是服务器型号，而是Kafka集群每天要接收多少数据，以及这些数据怎样变化。至少需要确认以下负载特征：
持续写入量：看消息字节数或写入字节速率，不要只看每秒请求数。每秒一万条几十字节的消息，与同样请求数下每条数十KB的消息，存储需求相差很大。请求类型：生产请求主要决定写入量；消费请求通常不会直接增加日志存储，但消费者处理延迟会影响故障排查和数据追赶能力。若同时启用压缩或日志压实，还要分别考虑其磁盘行为。峰值形态：记录峰值速率和持续时间。短时尖峰影响缓冲与磁盘写入能力；持续数小时的高峰则会明显增加当天数据量。用峰值速率直接乘整天时长，通常会高估；只用低峰时段的速率，则可能低估。消息尺寸与结构：消息体、键、头部、批次组织方式都会影响存储大小。若生产端上报的是业务载荷字节数，不应直接视为Kafka磁盘上的实际字节数。增长速度：新业务接入、流量季节性变化、留存要求延长、分区增加，都可能改变未来的磁盘需求。增长率要绑定明确的时间跨度，例如月增长率或年增长率，避免把两者混用。分布是否均匀：集群总量看起来充足，不代表每台Broker都安全。分区副本分配不均、热点分区或故障后的副本迁移，都可能让少数服务器先达到容量或吞吐瓶颈。对于已有集群，优先使用一段具有代表性的监控数据，观察按小时和按天汇总的写入字节数、Broker磁盘增长量、消息压缩前后差异及分区分布。观察周期应覆盖业务高峰、低峰和常见批处理任务；若业务有明显月度或季节周期，短期数据不足以代表长期负载。
二、把保留时间换算为磁盘数据量在使用十进制单位估算时，1 GB = 1,000 MB，1 TB = 1,000 GB。若已知某一口径下的持续写入速率，可按以下关系计算：
保留数据量（GB）≈ 每秒写入量（MB/s）×保留秒数÷1,000
再把消息压缩、复制因子等因素加入计算。为了避免重复计算，先明确“写入量”指什么：
如果使用的是压缩后的单副本磁盘写入速率，计算结果已经反映压缩效果，不要再乘一次压缩比例。如果使用的是未压缩的逻辑数据速率，可以用实际测得的压缩后与压缩前数据量之比估算压缩系数，再乘复制因子。如果使用的是整个集群所有Broker的磁盘增长量，数据中通常已经包含副本，不应再次乘复制因子。一个用于说明计算过程的示例：假设集群每秒接收10 MB的未压缩消息，长期平均压缩后占原始数据的50%，复制因子为3，目标保留7天。此处假设10 MB/s是集群逻辑数据速率，压缩比例和流量在这7天内保持不变，且暂不计索引与其他空间开销。
未压缩数据在7天内为：
10 MB/s × 86,400秒/天 × 7天 ÷ 1,000 = 60,480 GB
压缩后单副本约为：
60,480 GB × 50% = 30,240 GB
考虑3份副本，集群日志数据约为：
30,240 GB × 3 = 90,720 GB，约90.7 TB
这不是某台服务器的承载保证，而是按给定假设推演的集群数据量。实际压缩效果会随消息内容、批次大小和生产配置变化；日志索引、文件系统开销以及清理期间旧段尚未删除等情况，也会使实际磁盘占用高于简化估算。
若能直接取得集群各Broker的实测磁盘增长量，通常比用业务载荷推算更接近最终结果。可在代表性时间段内计算：
单副本磁盘增长速率 = Broker日志目录新增字节数 ÷ 观察秒数
再按目标保留时长外推，并检查该时段内是否发生过日志清理、分区迁移或扩缩容。若观测到的是集群总磁盘增长量，就直接按集群口径使用，不再叠加副本系数。
三、理解Kafka保留策略：时间与容量可能谁先到就谁先清Kafka的日志保留不是简单地为每条消息单独计时。日志通常按段文件组织，Broker在日志清理时检查符合条件的日志段，因此实际释放空间会受段滚动和清理检查周期影响，可能晚于配置值所表示的时间或容量边界。
常见的删除策略涉及两个不同维度：
按时间保留：Broker级别常见配置为 log.retention.ms，也可在Topic层设置对应的保留时间。时间单位是毫秒。配置前应确认当前Kafka版本支持的配置项及Topic是否存在覆盖值。按容量保留：log.retention.bytes用于限制日志容量，常见含义是按分区限制，而不是给整个集群设一个统一容量上限。一个Topic有多个分区时，不能把该值直接当作Topic总上限；还需结合分区数与副本数估算。清理方式：设置为删除策略的日志段到达清理条件后可被删除；压实策略的Topic则有不同的数据保留语义，不能把普通删除型日志的估算直接套用。若Topic同时使用压实与删除策略，还需结合其配置和业务读取需求判断可回溯范围。实际规划应将保留时间与容量上限一起看。若配置的容量限制先于时间窗口触发，系统可能为了满足容量约束删除更早的数据；若时间条件先达到，日志按时间清理。分区间数据量不均时，按分区设置的容量限制还可能导致热点分区比其他分区更早触发清理。
消费者延迟不会自动阻止Kafka删除已达到保留条件的日志。若消费者停滞时间超过日志保留窗口，恢复后可能无法从原有位置继续读取。因此，排查和恢复需求不能只看日志保留设置，还要核对消费者最长可能中断时间、可接受的数据重放窗口及备份或上游重建能力。
四、判断真正的瓶颈：容量、吞吐和副本分布要分开看磁盘空间不足只是其中一种风险。Kafka还可能在磁盘吞吐、网络带宽、Broker负载或副本同步上先遇到瓶颈。容量规划时要区分“能放多少数据”和“能否在峰值时及时写入、复制与清理”。
观察项可能的容量或性能风险判断时需要结合的指标磁盘空间日志增长快于清理，剩余空间持续下降各Broker可用空间、日志目录增长量、预计达到预警线的时间磁盘吞吐与延迟峰值写入、读取或副本追赶造成I/O排队磁盘读写吞吐、I/O等待、请求延迟及业务峰值Broker间分布个别节点先满，集群平均值掩盖热点每台Broker及每块挂载盘的占用、分区副本分布副本同步流量升高或节点故障后，副本追赶速度不足副本同步状态、落后程度、网络吞吐和磁盘写入能力清理效果逻辑上已到期，但文件空间未及时释放日志段删除情况、清理周期、文件系统实际可用空间需要特别留意：磁盘容量按集群总量汇总，可能掩盖单Broker热点；磁盘吞吐则可能在空间尚充足时先成为瓶颈。新建服务器、扩充磁盘或增加Broker之前，应确认瓶颈位于哪一层。若只是分区分布不均，扩容后的数据重分配计划也会影响短期网络和磁盘负载。
Kafka日志的保留窗口与磁盘规划，离不开适配持续写入和数据增长的服务器资源。A5idc数据提供香港、美国、日本等地区的物理服务器租用，涵盖Xeon Gold、AMD EPYC等平台及SSD、NVMe存储方案，也有大容量硬盘配置，可为Kafka集群的数据写入、日志存放和业务部署提供多样化的硬件基础。
五、为峰值、清理延迟和增长预留容量估算出的日志数据量不能直接等同于磁盘采购量。服务器还要容纳操作系统、日志与监控文件、临时文件及其他服务数据；Kafka日志所在文件系统也应保留可用空间，不能长期按接近满盘的状态运行。磁盘预留比例应根据峰值波动、故障迁移速度、扩容周期和运维响应时间确定。
常见做法是先设定一个目标使用率，再反推所需可用容量：
规划容量 = 预测日志占用量 ÷ 目标使用率
例如，若某一预测周期内日志数据预计占用9.1 TB，团队将70%作为日志盘的规划使用率目标，则所需可用容量约为：
9.1 TB ÷ 70% = 13.0 TB
这13.0 TB是该口径下的可用盘容量估算，不等于磁盘标称容量，也未自动包含操作系统盘或其他目录。若预测9.1 TB尚未计入分区倾斜、清理滞后和故障迁移，应先补入这些变量，再进行除法计算。目标使用率不是Kafka固定要求，应根据磁盘类型、业务突发程度和扩容响应时间设置；扩容周期越长，通常越需要保留更大的安全余量。
增长预测也要进入容量预算。若当前预计日志占用9.1 TB，规划一年后增长20%，则一年后的数据量约为：
9.1 TB × 1.20 = 10.92 TB
若仍以70%作为规划使用率，所需可用容量约为：
10.92 TB ÷ 70% = 15.6 TB
这个估算假定保留时间、压缩比例与副本因子不变。如果业务增长同时伴随保留窗口延长，或压缩效果下降，容量会比单纯按流量增长更快。反之，若扩容包含增加分区或调整副本分布，也要评估数据迁移期间的临时磁盘与网络压力。
六、保留多久：按排查窗口确定时间，再用容量校验Kafka日志保留时间没有适用于所有业务的固定天数。决策应从故障定位链条反推：常见异常多久可能被发现，定位需要查看多长时间范围，消费者最长可能落后多久，是否必须重放历史数据，以及这些数据能否从其他系统恢复。
可以将候选窗口分为三类来评估：
短期排障窗口：适合业务事件发现快、主要用于追查近期请求与处理异常的Topic。窗口应覆盖监控发现延迟、值班响应和常见复现时间。数据重放窗口：适合消费者故障后需要重新读取消息的Topic。窗口至少应覆盖可接受的最长消费中断和恢复时间，并留出副本追赶及排查余量。长期留存需求：若出于审计、长期分析或合规要求需要保存更久，应先确认数据类型、访问方式与保留要求。Kafka在线日志不一定是长期归档的合适承载方式，可将归档与在线服务的容量预算分开评估。时间窗口确定后，用消息速率和磁盘增长数据校验容量是否支持该窗口。若容量不够，可以比较延长扩容周期、调整Topic保留时间、优化消息体积或压缩、调整副本策略等方案的影响。不能只为了释放空间而降低副本数或缩短所有Topic的保留时间：前者改变故障容忍能力，后者可能使排查或消费恢复窗口不足。不同业务Topic的可靠性与回溯需求不同，策略也应分别核对。
七、用监控阈值确定扩容触发点扩容阈值应由“多久会触及安全线”和“扩容需要多久”共同决定，而不是等到磁盘报警后再处理。对每台Broker及对应日志盘，持续跟踪可用空间、近几天的磁盘增长速度、分区副本分布、写入峰值、磁盘延迟和副本同步情况。
可按以下方法制定触发规则：
设定硬安全线与预警线：硬安全线是团队不希望触及的最低可用空间；预警线要更高，并确保从触发到完成扩容、数据重分布或流量调整的时间内，磁盘仍有余量。具体比例应按历史波动和响应周期确定。估算剩余时间：可用空间除以近期代表性增长速率，得到大致的“按当前速度到达安全线时间”。增长有明显日夜峰值时，不能只用低谷速率；可同时计算常态和高峰场景。对照扩容周期：若预计到安全线的时间小于采购、交付、部署和数据均衡所需时间，应提前扩容或调整容量策略。增加服务器并不意味着数据立即均匀分布，重分配过程也需要资源。设置复核条件：当实际磁盘增长连续偏离预测、压缩比例变化、Topic分区增加或保留时间调整时，重新计算容量。若只有单台Broker占用异常，应先确认分区与副本倾斜，再判断是否需要全局扩容。最终的保留期限应同时满足业务回溯窗口与容量预算；扩容阈值则应让团队在剩余空间不足之前，仍有时间完成交付和数据均衡。将这两项与每台Broker的磁盘增长速率、峰值写入和副本状态一起监控，才能让Kafka日志既保留得够用，也不把服务器长期推向满盘边缘。