Kafka面试题

1.生产者

1.1 消息丢失

1.1.1 原因

• acks=0或者1
• 未启用重试机制
• 对失败消息没做处理

1.1.2 如何防止消息丢失

• 配置acks=all: 确保消息在分区的所有同步副本(ISR副本: Leader + Follower)都成功收到后，才向生产者确认。

  • 存在的问题: Broker在处理消息时遇到临时故障，例如某个副本不可用，此时会向生产者返回一个错误响应。如果生产者没有重试机制，那么在收到错误响应后，生产者可能会直接丢弃该消息，从而导致消息丢失。

• 启用重试机制: 生产者在遇到临时故障时会自动重试发送消息

  • 作用: 主要是为了解决短暂的、可以在短时间内恢复的故障(临时故障、网络波动、副本重启、临时资源不足等)。
  • 存在的问题: 当重试次数达到设定的最大重试次数后，如果消息仍然无法成功发送，消息就会被丢弃，从而导致消息丢失。

• 监控失败消息: 生产者可以通过实现Callback接口，在消息发送成功或失败时执行特定的逻辑。这种方法允许生产者在消息发送失败后执行自定义的处理逻辑，从而进一步减少消息丢失的风险。

1.2 消息重复发送

1.2.1 原因

• 网络问题: 网络延迟或中断可能导致生产者在发送消息时未收到Broker的确认（ACK），即使Broker已经成功接收并存储了消息。生产者会认为发送失败，并重新发送消息，导致消息重复。
• 生产者重试机制: 当生产者没有收到Broker的确认时，它会根据配置的重试策略自动重试发送。每次重试都可能导致消息被重复发送。
• Broker故障: 如果Broker在消息处理后但在返回确认之前崩溃，生产者未能收到确认，可能会重发消息，导致Broker在恢复后收到重复的消息。
• 重启或故障恢复: 如果生产者在发送消息过程中发生崩溃或重启，可能会在恢复后重发之前的消息，导致重复。

1.2.1 如何防止消息被重复发送

• 启用幂等性: Kafka生产者的幂等性是通过记录每一条消息的身份信息（生产者ID和消息序列号）来实现的。这个机制确保了即使在网络故障或重试情况下，消息也不会被重复写入到Kafka主题中。
• 使用事务性生产者: 事务性生产者允许多个消息的发送作为一个原子操作，确保这些消息要么都成功，要么都失败。这在处理需要跨多个Topic或分区的事务时尤为重要。在事务中发送消息时，即使在故障情况下，也不会出现部分消息写入的情况，从而避免重复处理。

1.3 消息的序号

• 消息在生产者端，有一个独立序号，即Sequence Number，用来实现幂等性，防止消息被重复发送。
• 消息在broker端，有一个独立序号，即Offset，帮助消费者跟踪消费进度。

2.消费者

2.1 消息丢失

2.2 消息重复消费

消费者消费后没有commit offset

• 消费者崩溃或强行杀死：如果消费者在处理消息时崩溃或被强行杀死，消息的偏移量可能尚未提交。因此，重启后的消费者会从最后成功提交的偏移量之后开始消费，从而重新处理那些未提交偏移量的消息
• 自动提交偏移情况，异常时，偏移量未提交: 即使消息处理失败，但偏移量还未提交，那么此时消费者进程退出或重启，由于偏移量未提交，消费者会重新消费之前未标记为已消费的消息，这就会导致消息的重复消费

2.2.1 如何防止消息被重复消费

• 手动提交偏移量: 使用手动提交偏移量的方法，以便在成功处理消息后明确提交偏移量，确保处理逻辑的正确性。

3.消费者组

3.1消费者组的作用