Kafka如何防止消息丢失

Kafka防止消息丢失的实用方案

总体思路

• 从生产者、Broker、消费者三端协同治理，目标是让消息在被认定为“已提交”后不再丢失，并在异常场景下可重试或回放。Kafka提供三种传递语义：至少一次（at least once）、至多一次（at most once）、精确一次（exactly once）。在绝大多数业务下，采用acks=all + 重试 + 幂等/事务的组合，配合手动提交位移，即可在可接受的延迟与成本内实现“不丢”。

生产者端配置

• 使用带回调的发送方式：不要“发后即忘”，务必处理 send 的回调，感知超时、拒绝等异常并做重试或落库补偿。
• 设置确认级别：将acks=all（或**-1**），确保消息被Leader写入并收到ISR中足够副本的确认后再认为成功。
• 开启重试与退避：配置retries > 0（如3–5或更大）、retry.backoff.ms（如100–20000 ms），应对网络抖动、Leader切换等瞬时故障。
• 启用幂等性：设置enable.idempotence=true，在单会话、单分区内避免重试导致的重复；注意幂等性不跨会话、不跨分区。
• 控制并发与顺序：根据是否需要严格顺序，权衡max.in.flight.requests.per.connection（如设为1可保序但吞吐下降）。
• 消息大小与限流：确保max.request.size小于 Broker 的message.max.bytes，避免被 Broker 拒绝。
• 语义选择：若业务可容忍重复但绝不能丢，使用至少一次；若既要不丢又要不重，使用幂等/事务实现精确一次。

Broker端配置

• 副本与可用性：将主题的replication.factor ≥ 3，提升容灾能力。
• 最小同步副本：设置min.insync.replicas ≥ 2，与acks=all配合，定义“已提交”的门槛；推荐关系：replication.factor = min.insync.replicas + 1，保证在单副本故障时仍满足最小同步副本数。
• 禁止脏选主：设置unclean.leader.election.enable = false，避免落后太多的副本成为 Leader 导致数据截断。
• 持久化权衡：Kafka默认依赖Page Cache + 异步刷盘，断电可能丢失未落盘数据；可通过log.flush.interval.messages/ms等参数缩短刷盘间隔以提升可靠性（会牺牲吞吐）。
• 监控与告警：监控UnderReplicatedPartitions、ISR收缩、Broker 磁盘/IO、请求时延等，及时处置异常。

消费者端配置

• 关闭自动提交：设置enable.auto.commit=false，在业务处理成功后再手动提交位移（同步或异步），避免“处理未完成却已提交”导致丢失。
• 可靠提交策略：处理一批消息后提交该批最大 offset；若处理需跨多个步骤/系统，采用事务或“将处理结果和 offset 原子写入同一存储”的方式，确保“处理与提交”要么都成功，要么都不提交。
• 读取事务消息：若从 Kafka 读取并写回 Kafka，消费者设置isolation.level=read_committed，只读取已提交事务。
• 失败处理：对处理失败的消息进行重试、落库/死信队列（DLQ），避免丢弃。

常见误区与排查清单

• 误区一：认为acks=all就绝对不丢。若replication.factor=1或min.insync.replicas=1，Leader 宕机仍可能丢数据；需保证多副本 + 最小同步副本 ≥ 2。
• 误区二：开启自动提交且“先提交再处理”。一旦处理失败，已提交位移导致后续无法重放，消息丢失；应改为处理完再提交。
• 误区三：忽视消息大小与Broker 限流，导致发送被拒或异常；需对齐max.request.size与message.max.bytes。
• 排查清单：
  1. 生产者是否使用回调、是否开启重试与幂等；
  2. acks是否为all，且min.insync.replicas与replication.factor配置合理；
  3. 是否禁用自动提交、是否在处理成功后提交位移；
  4. 是否存在脏选主（unclean leader election）；
  5. 监控UnderReplicatedPartitions、ISR变化、Broker 磁盘/IO、请求错误率。