在 Spring Kafka 场景下，要实现消息不丢失并非通过单一配置就能完成，而是需要从生产者、消费者以及集群配置等多个维度协同发力，形成一套完整的保障策略。下面我们将逐一解析那些关键的配置点和实战技巧。
生产者确认机制：三种级别，权衡安全与性能
生产端最直接的保障参数就是 acks。这个参数的选择会直接影响消息投递的可靠性，绝对不能忽视。
- acks=0：发送即忘，生产端不等待任何服务端确认。这种模式下吞吐量最高，但消息丢失时毫无感知——例如网络闪断或分区无领导者，消息会直接从客户端消失。适用于日志量极大且可容忍少量丢失的业务场景。
- acks=1：仅等待领导者分区写入本地日志即返回，不等待 ISR 中其他副本同步。延迟敏感的应用通常会选用此级别，但若领导者宕机且副本尚未同步，消息仍有丢失风险。
- acks=all：必须等待 ISR 中所有副本都确认写入，这是最安全的配置。代价是吞吐量明显降低，但数据安全保障最强，适合对可靠性要求极高的核心业务。
在 Spring Kafka 中，你可以在 application.yml 或 application.properties 中设置 spring.kafka.producer.acks=all，也可以通过构造 KafkaTemplate 时传入 ProducerFactory 自定义 ProducerConfig.ACKS_CONFIG 属性来实现。
重试机制：为发送失败提供补救机会
仅靠确认机制还不够，网络抖动、临时节点不可用等瞬时故障时常发生。此时 retries 参数就至关重要——它定义了生产者在放弃前重试的次数。配合 retry.backoff.ms 控制重试间隔，可以避免重试风暴对集群造成冲击。
Spring Kafka 的配置方式非常简洁：在生产者配置中添加以下参数：
spring.kafka.producer.properties.retries=3
spring.kafka.producer.properties.retry.backoff.ms=500
当然，重试次数需要结合业务实际可承受的延迟来设定，无限重试会导致消息积压甚至死循环，务必谨慎。
幂等性生产者：从源头杜绝重复
如果生产者重试后成功发送，但 Kafka 的确认响应丢失，生产者会误以为发送失败而再次重试，这就可能导致同一条消息被多次写入。开启幂等性（enable.idempotence=true）后，Kafka 会为每个生产者会话分配唯一 ID，并为每条消息分配序列号，确保即便重试，broker 也能自动去重。
注意：幂等性要求 acks 必须为 all，且 retries 不能为 0。在 Spring Kafka 中开启非常简单：
spring.kafka.producer.properties.enable.idempotence=true
分区策略：保障顺序消费的关键
虽然分区策略与消息丢失没有直接关系，但顺序性在不少场景中等同于“不丢失上下文”。如果你依赖消息顺序，就不能依赖默认的分区策略。通过自定义 Partitioner，你可以根据业务键将消息路由到固定分区，这样同组消费者就能按分区顺序消费。
实现 org.apache.kafka.clients.producer.Partitioner 接口后，通过 ProducerConfig.PARTITIONER_CLASS_CONFIG 注入即可启用。
消费者组：高可用的基本架构
单条消息成功写入 Kafka 只是第一步，如果消费者宕机或处理过程中崩溃，消息依然可能丢失。将消费者组织成组（group.id）后，Kafka 会自动把分区分配给组内存活的消费者实例，宕机时触发重平衡，由其他消费者接管分区。这样即使服务节点挂掉，消息也能被其他实例继续消费。
在 Spring Kafka 中，通过以下配置指定消费者组：
spring.kafka.consumer.group-id=my-group
监控与日志：最后一道防线
所有配置都是防御性手段，真正能发现问题的还是完善的监控和日志。建议持续关注 Kafka 集群的吞吐量、请求延迟和错误率，同时为生产端的 send 回调以及消费端的 @KafkaListener 异常添加详细的日志输出。一旦出现发送失败或消费异常，就能第一时间定位并处理。
没有任何单一配置能拍胸脯保证消息永不丢失，但将上述策略组合起来，结合业务对数据可靠性的实际容忍度进行权衡，就能将丢失概率降至足够低。毕竟，架构设计的本质就是一场关于安全、性能和成本的博弈。
