面试题：微服务架构下Kafka消息丢失场景及解决办法

Question

在微服务架构中使用Kafka时，可能会出现消息丢失的情况。请列举至少两种可能导致消息丢失的场景，并说明相应的解决办法。

Answer 1

生产者消息丢失

1. 场景：生产者发送消息到Kafka，由于网络波动等原因，生产者未收到Kafka的确认响应，此时生产者可能认为消息发送失败而丢弃消息。
2. 解决办法：
   • 设置合适的 acks 参数，如 acks=all，表示所有副本都确认收到消息后，生产者才认为消息发送成功。这样可以保证消息不会因为部分副本未收到而丢失。
   • 开启重试机制，设置 retries 参数为大于0的值，当消息发送失败时，生产者会自动重试。同时要注意设置合理的 retry.backoff.ms 参数，控制重试间隔时间，避免频繁重试导致性能问题。

消费者消息丢失

1. 场景：消费者从Kafka拉取消息后，在处理消息过程中发生故障，而此时消费者已经向Kafka提交了消费偏移量，导致该消息实际上未被成功处理就被认为已消费，下次不会再拉取到该消息，从而造成消息丢失。
2. 解决办法：
   • 采用手动提交偏移量的方式，在消息成功处理后再手动提交偏移量。这样可以确保消息被成功处理后才标记为已消费。在Java中使用KafkaConsumer时，可以通过 commitSync() 或 commitAsync() 方法手动提交偏移量。
   • 可以使用事务机制来保证消息处理和偏移量提交的原子性。比如在Kafka Streams中，可以利用事务来确保消息处理和状态更新以及偏移量提交要么全部成功，要么全部失败。

Kafka 副本间消息丢失

1. 场景：Kafka集群中有多个副本，当leader副本发生故障，而follower副本还未完全同步leader副本的消息时，选举新的leader后，那些未同步的消息就会丢失。
2. 解决办法：
   • 设置合理的 min.insync.replicas 参数，比如设置为2，表示至少有2个副本（包括leader副本）在ISR（In - Sync Replicas）列表中，消息才会被认为是已提交的。这样可以防止leader故障时，未同步的消息丢失。
   • 开启 unclean.leader.election.enable 参数为 false，禁止非ISR中的副本成为leader。如果允许非ISR副本成为leader，可能会导致数据丢失，设置为 false 后，只有ISR中的副本才有资格成为leader，可一定程度保证数据一致性，避免消息丢失。