面试题
- 1.生产者
-
- [1.1 消息丢失](#1.1 消息丢失)
-
- [1.1.1 如何防止消息丢失](#1.1.1 如何防止消息丢失)
- [1.2 消息重复发送](#1.2 消息重复发送)
-
- [1.2.1 如何防止消息被重复发送](#1.2.1 如何防止消息被重复发送)
- [1.3 消息的序号](#1.3 消息的序号)
- 2.消费者
-
- [2.1 消息丢失](#2.1 消息丢失)
- [2.2 消息重复消费](#2.2 消息重复消费)
-
- [2.2.1 如何防止消息被重复消费](#2.2.1 如何防止消息被重复消费)
- 3.消费者组
1.生产者
1.1 消息丢失
很多原因会导致生产者消息丢失，其中没有设置合理的acks参数是导致消息丢失的常见原因。
- 不恰当的acks参数配置
- 生产者未启用重试机制
1.1.1 如何防止消息丢失
- 配置acks=all : 确保消息在分区的所有同步副本(
ISR副本: Leader + Follower)都成功收到后，才向生产者确认。
即使设置了acks=all，Broker在处理消息时遇到问题(如副本不可用、存储故障等)，并且无法从所有同步副本获得确认，Broker会向生产者返回一个错误响应。在这种情况下，如果生产者没有重试机制，消息在收到错误响应后会被丢弃，最终导致消息丢失。 - 设置合理的重试次数 : 通过设置
retries参数，生产者在遇到临时故障时会自动重试发送消息
即使启用了重试机制，如果生产者在达到最大重试次数后仍未能成功发送消息，消息还是会被丢失。 - 监控失败消息 : 通过使用
Callback回调函数，捕获发送失败的消息，并进行相应的处理，如记录日志或将失败的消息存储到一个备用存储中（例如数据库、文件系统）以便后续处理。
1.2 消息重复发送
由于网络重试或幂等性配置不当，生产者可能会多次发送同一条消息，导致消息重复。
- 网络故障或超时: 如果生产者在发送消息后没有收到 Broker 的确认(可能由于网络问题或Broker超时)，它可能会重新发送相同的消息以确保消息到达。
- 生产者崩溃或重启: 如果生产者在发送消息后崩溃或重启，且消息的成功写入没有得到确认（因为没有启用重试机制），生产者可能会在重启后尝试重新发送消息。
- 生产者重试机制: 如果生产者配置了重试机制（retries 参数），在发送消息失败时，生产者会尝试重新发送消息。如果发送失败的原因是暂时性的（如网络问题），这些消息可能会被重复发送。
1.2.1 如何防止消息被重复发送
- 启用幂等性 : 启用幂等性确保即使生产者重试发送消息，Kafka 也会保证每条消息只会被处理一次。这是因为幂等性机制会防止同一消息在网络问题或生产者重试时被重复写入。
kafka通过记录每一条信息身份信息(生产者ID+消息序列号)来实现幂等性。 - 使用生产者事务: 使用Kafka事务可以确保一组消息的原子性，要么全部成功，要么全部不成功。在事务中发送消息时，即使在故障情况下，也不会出现部分消息写入的情况，从而避免重复处理。
1.3 消息的序号
- 消息在生产者端，有一个独立序号，即
Sequence Number，用来实现幂等性，防止消息被重复发送。 - 消息在broker端，有一个独立序号，即
Offset，帮助消费者跟踪消费进度。
2.消费者
2.1 消息丢失
2.2 消息重复消费
消费者消费后没有commit offset
- 消费者崩溃或强行杀死：如果消费者在处理消息时崩溃或被强行杀死，消息的偏移量可能尚未提交。因此，重启后的消费者会从最后成功提交的偏移量之后开始消费，从而重新处理那些未提交偏移量的消息
- 自动提交偏移情况，异常时，偏移量未提交 : 即使消息处理失败，但偏移量还未提交，那么此时消费者进程退出或重启，由于偏移量未提交，消费者会重新消费之前未标记为已消费的消息，这就会导致消息的
重复消费
2.2.1 如何防止消息被重复消费
- 手动提交偏移量: 使用手动提交偏移量的方法，以便在成功处理消息后明确提交偏移量，确保处理逻辑的正确性。