kafka 生产者 `buffer.memory` 中未发送的数据在应用崩溃或进程终止时会永久丢失；真正的数据可靠性依赖于 broker 端的副本机制与合理配置，而非客户端内存缓冲。
在 Kafka 生产者中，buffer.memory（默认 32 MB）用于暂存待发送的消息批次（batches），这些数据驻留在应用进程的 JVM 堆内存中，尚未序列化到网络或提交至 Kafka Broker。一旦生产者应用异常崩溃、被强制 kill 或 JVM 进程退出，该内存区域将被操作系统立即回收——所有未成功发送并确认（acknowledged）的消息将不可恢复地丢失。这与磁盘持久化无关，因为此时数据甚至未离开客户端本地。
例如，以下配置的生产者在崩溃前若仍有积压在缓冲区中的消息：
Properties props = new Properties();
props.put("bootstrap.servers", "kafka-broker-1:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("buffer.memory", "33554432"); // 32 MB
props.put("acks", "1"); // ⚠️ 风险配置：仅等待 leader 写入即返回
props.put("retries", Integer.MAX_VALUE);
props.put("enable.idempotence", "false");若此时应用崩溃，且 acks=1（仅 leader 确认），而该 leader 尚未将消息复制给 ISR（In-Sync Replicas）副本，那么即使 Broker 本身仍在运行，该消息也处于“单点存储”状态——一旦该 leader 所在 Broker 后续宕机且无副本可用，消息仍将丢失。
✅ 真正保障数据不丢失的关键不在客户端缓冲区，而在服务端的多副本与持久化策略：
- Kafka 通过 副本机制（Replication） 实现容错：每个分区（Partition）可配置 replication.factor ≥ 3，确保消息被同步写入多个 Broker；
- 结合 min.insync.replicas=2 与 acks=all，可强制要求消息必须被至少 2 个同步副本写入磁盘后才向生产者返回成功响应；
- Broker 端启用 log.flush.interval.messages 或 log.flush.interval.ms（虽通常不建议频繁刷盘，但配合 unclean.leader.election.enable=false 可避免脏选举导致的数据回退）。
⚠️ 注意事项：
- buffer.memory 是客户端资源控制参数，不是持久化层，不可用于故障恢复；
- 启用幂等生产者（enable.idempotence=true）可防止重试导致的重复，但无法挽回已丢失的缓冲区内存数据；
- 若需端到端精确一次（exactly-once）语义，应结合事务（transactional.id）与下游消费者支持；
- 监控 buffer-available-bytes 和 record-queue-time-avg 等 JMX 指标，及时发现缓冲区积压，避免因网络抖动或 Broker 延迟引发批量丢数风险。
总结：缓冲区数据的生命期严格绑定于生产者进程生命周期。要构建高可靠消息链路，必须放弃“从客户端内存恢复”的思路，转而通过 Broker 多副本 + 强一致性 ack 策略 + 合理重试/幂等/事务机制 构建纵深防御体系。
