kafka面试之如何防止消息丢失、重复消费、消息挤压_kafka面试避免重复消费

前言

kafka的关键名词

生产者：producer      主机：broker      主题：topic      消费者：consumer      分区：partition      领导者副本：leader      追随者副本：follower 

推：push     拉：pull 

问题一：如何防止消息丢失

生产者端可以利用acks机制防止消息丢失

1，设置异步发送

同步发送：数据量过大会产生阻塞，所以一般使用异步

异步发送：实现回调方法，消息发送失败时记录日志，或者重新发送最终确保消息发送成功

2，设置消息重试机制

acks：acks是一种确认应答机制，参数制定写入多少个分区副本收到消息生产者才会认为消息写入成功，参数配置值有0、1、-1或all具体含义如下：

  0：生产者完全写入前不会等待服务器也就是broker任何响应，如果服务器出现问题，例如网络波动，生产者无从得知，从而导致消息丢失，这也就是kafka为什么可以以网络最大速率发送消息达到很高的吞吐量

  1:leader分区接受到消息回立马向生产者发送确认响应，如果此时leader副本写入完后会发送应答，还未开始向follower同步，新的leader也不会收到同步的消息则消息丢失

  -1/all：是需要等待leader和follower都写入完成才会向生产者发送响应

消费端可以利用offset机制向broker提交回应

 消费端offset默认为自动提交，在消息拉取后消费端会自动向broker提交，如果这是消费端挂了，消息的业务代码块还没跑完，这时消息会丢失即便重启也无法再次拉取消息，所以这时我们需要将offset改成手动提交，在我们执行玩业务代码块后手动向broker提交回应

  总结：生产端选择合适acks机制，消费端根据业务场景选择手动还是自动

问题二：如何防止重复消费

消费端无论offset时自动提交还是手动提交都要摸人接受有重复消费的情况，

解决方案

一，是通过事务确保消息的精准一次性处理

二，为每条消息添加唯一标识符，在生产端可以确保不会重复发送，在消费端可以用来检查是否消费过，消费过直接忽略，说白了就是幂等性原理

问题三：消息积压

解决思路：

• 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
• 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
• 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
• 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
• 等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。