kafka 生产者 `buffer.memory` 中未发送的数据在应用或进程崩溃时会丢失，因其属于进程内内存；真正可靠的消息持久化依赖 kafka 的磁盘写入、副本机制和生产者重试配置，而非内存缓冲。
在 Kafka 生产者客户端中，buffer.memory（默认 32 MB）用于暂存待发送的消息批次（batches），这些数据驻留在 JVM 堆内存中，由 RecordAccumulator 管理。关键事实是：该缓冲区完全位于生产者应用进程内部——一旦应用异常终止（如 OOM、kill -9、JVM 崩溃）或所在服务器宕机，缓冲区内尚未被 Sender 线程提交到网络层的数据将彻底丢失，无法恢复。
这并非 Kafka 设计缺陷，而是权衡吞吐与一致性的明确取舍：内存缓冲提升批处理效率，但不提供进程级故障恢复能力。真正的可靠性保障需通过以下协同机制实现：
✅ 生产者端增强配置（防止数据过早丢失）
Properties props = new Properties();
props.put("bootstrap.servers", "kafka1:9092,kafka2:9092,kafka3:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 关键可靠性参数
props.put("acks", "all"); // 等待所有 ISR 副本确认写入
props.put("retries", Integer.MAX_VALUE); // 启用无限重试（配合 retry.backoff.ms）
props.put("enable.idempotence", "true"); // 启用幂等性，避免重复发送（需配合 max.in.flight.requests.per.connection <= 5）
props.put("max.in.flight.requests.per.connection", "5");
props.put("delivery.timeout.ms", "120000"); // 总交付超时（含重试），避免卡死✅ Broker 端高可用设计（保障已接收消息不丢失）
- 消息一旦被 Broker 接收并成功写入本地磁盘（经 log.flush.interval.messages 或 log.flush.interval.ms 触发落盘），即具备持久性基础；
- 通过 replication.factor ≥ 3 和 min.insync.replicas = 2 配置，确保即使单节点宕机，ISR（In-Sync Replicas）中仍有足够副本持有完整数据；
- unclean.leader.election.enable = false（默认）可防止非同步副本意外成为 Leader 导致数据回退。
⚠️ 重要注意事项
- buffer.memory 是生产者本地资源，与 Broker 的 log.dirs 磁盘、副本同步状态完全无关；它不提供跨进程/跨机器恢复能力；
- 不要试图“从缓冲区重新生成数据”——缓冲区内容在进程死亡后即不可访问，正确的做法是：在业务层实现上游幂等性（如基于业务 ID 去重）或事务性消息补偿机制（如结合数据库 binlog 或状态快照）；
- 若需端到端精确一次（exactly-once）语义，应启用 Kafka 事务（transactional.id）并配合 isolation.level=read_committed 消费。
总结而言，Kafka 的可靠性模型是分层的：buffer.memory 负责性能优化，而持久性由 Broker 的磁盘持久化 + 多副本复制 + 生产者重试/幂等性共同保障。理解这一职责边界，才能合理设计容错策略——不依赖内存缓冲做故障恢复，而用架构手段规避其单点风险。
