3. 消息丢失的根因分类：生产端丢失、Broker端丢失、消费端丢失

在微服务链路中，Kafka 消息丢失的故障根因可以归纳为三个核心环节：生产端（Producer）、Broker 端和消费端（Consumer）。每个环节的丢失机制、触发条件和排查路径截然不同。本节从故障排查视角，对三类丢失进行结构化分类与深度解析。

3.1 生产端丢失

生产端丢失发生在消息从微服务应用发出到 Broker 确认接收的过程中。常见根因包括：

• 异步发送未处理回调：使用 producer.send() 但未注册 Callback，发送失败时无感知。
• acks 配置不当：acks=0 或 acks=1 在 Leader 副本崩溃时可能丢失。
• 网络超时与重试耗尽：配置的 retries 过小或 delivery.timeout.ms 过短，导致消息在重试耗尽后被丢弃。
• 消息体过大：超过 max.request.size 或 Broker 端 message.max.bytes，被静默拒绝。
• 序列化异常：自定义序列化器抛出异常，消息未进入发送队列。

3.2 Broker 端丢失

Broker 端丢失发生在消息已到达 Kafka 集群，但在持久化或副本同步过程中丢失。这是最隐蔽的丢失类型，常见根因包括：

• Leader 副本崩溃且未完成同步：min.insync.replicas 配置为 1，Leader 宕机时未同步的消息丢失。
• 磁盘故障或页缓存刷写延迟：Broker 宕机时未刷盘的消息丢失（flush.messages 或 flush.ms 配置过大）。
• 日志截断（Log Truncation）：Leader 切换后，新 Leader 与旧 Leader 日志不一致，导致部分消息被截断。
• unclean.leader.election 启用：允许非 ISR 副本成为 Leader，可能丢失已提交但未同步的消息。
• 压缩（Compaction）误删除：日志压缩策略配置不当，导致未消费的消息被清理。

3.3 消费端丢失

消费端丢失发生在消息已成功存储于 Broker，但消费者在处理过程中丢失。常见根因包括：

• 自动提交位移导致处理中断：enable.auto.commit=true 且处理逻辑在提交位移后抛出异常，消息已提交但未处理完成。
• 消费线程崩溃：消息已拉取到本地缓冲区，但线程崩溃导致未处理的消息丢失。
• 位移重置或越界：消费者组位移被重置（如 auto.offset.reset=earliest 或 latest 配置不当），导致部分消息被跳过。
• 批量处理未做原子提交：一批消息中部分处理成功、部分失败，但位移已整体提交。
• 消费者 Rebalance 导致重复或丢失：Rebalance 期间未处理的消息被重新分配，但未正确保存处理状态。

// 手动提交 + 幂等消费示例
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
    for (ConsumerRecord<String, String> record : records) {
        try {
            // 业务处理（幂等）
            processMessage(record);
            // 处理成功后提交位移
            consumer.commitSync(Collections.singletonMap(
                new TopicPartition(record.topic(), record.partition()),
                new OffsetAndMetadata(record.offset() + 1)
            ));
        } catch (Exception e) {
            // 记录失败消息到死信队列或重试队列
            sendToDlq(record, e);
            // 继续处理下一条，避免阻塞
        }
    }
}

3.4 三类丢失的对比总结