**在 Linux 上无法做到对 Kafka 消息的“绝对不丢”，但可以通过正确配置把丢失概率降到极低，并在出现故障时保持“已提交消息不丢”的强保证。**Kafka 的持久化依赖操作系统与多副本机制：Linux 的 Page Cache 属于内存层，断电或崩溃会丢失未落盘数据；Kafka 本身不提供同步刷盘的强语义，因此极端故障场景（如节点突然掉电）仍可能丢失尚未落盘且未被确认为“已提交”的数据。官方保证的是“只要始终有至少一个 ISR 副本存活，已提交的消息不会丢失”。
端到端防丢配置清单
- 生产者
- 将 acks=all，确保写入被 ISR 中足够多的副本确认；开启 enable.idempotence=true 配合重试避免重试导致的重复；合理设置 retries（如 Integer.MAX_VALUE）、retry.backoff.ms（如 100–300 ms）、request.timeout.ms（如 30000 ms）；限制 max.in.flight.requests.per.connection（如 5，在启用幂等时上限为 5）以平衡吞吐与顺序/重试安全。
- Broker
- 将 replication.factor≥3，min.insync.replicas≥2，并保证 replication.factor > min.insync.replicas（常见组合：3/2 或 3/1）；关闭 unclean.leader.election.enable=false，避免落后太多的副本被选为 Leader 造成数据空洞；谨慎调整刷盘参数（如 log.flush.interval.messages/ms），仅在明确收益时改动，避免影响吞吐。
- 消费者
- 关闭 enable.auto.commit=false，采用“处理完成后再手动提交 offset”的策略；若需要“最多一次/至少一次”的语义，可配合业务幂等或 Kafka 事务（Exactly Once）。
典型场景与取舍
- 异步发送未等待回调或本地缓冲未落盘即崩溃：改用带回调的发送并配合重试/幂等，确保发送结果被确认后再认为成功。
- 自动提交 offset：改为手动提交，先处理再提交，避免“处理失败但已提交”的丢失；代价是可能出现重复，需要业务幂等。
- Leader 切换导致短暂不可用或数据空洞：通过 min.insync.replicas、replication.factor 与关闭 unclean.leader.election 降低风险，但极端掉电仍可能丢失未落盘的已确认数据（因 Page Cache）。
监控与运维要点
- 持续监控 UnderReplicatedPartitions、IsrShrinks、Broker 磁盘与网络；设置合理的 retention.bytes/retention.hours 避免磁盘打满导致写入失败；在升级/维护时遵循“先扩容再缩容、滚动重启”的流程，减少不可用窗口。
