Kafka 如何保证数据不丢失？不重复？

---

1、ack的配置策略

acks = 0

生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志。

acks = 1(默认值)

生产者发送消息之后，只要分区的leader副本成功写入消息，那么它就会收到来自服务端的成功响应。其实就是消息只发给了leader leader收到消息后会返回ack到producer端。如果消息无法写入leader时(选举、宕机等情况时)，生产都会收到一个错误的响应，为了避免消息丢失，生产者可以选择重发消息，如果消息成功写入，在被其它副本同步数据时leader　　崩溃,那么此条数据还是会丢失，因为新选举的leader是没有收到这条消息，ack设置为1是消息可靠性和吞吐量折中的方案。

acks = all (或-1)

生产者在发送消息之后，需要等待ISR中所有的副本都成功写入消息之后才能够收到来自服务端的成功响应，在配置环境相同的情况下此种配置可以达到最强的可靠性。即：在发送消息时，需要leader 向fllow 同步完数据之后，也就是ISR队列中所有的broker全部保存完这条消息后，才会向ack发送消息，表示发送成功。

2、retries的配置策略

在kafka中错误分为2种，一种是可恢复的，另一种是不可恢复的。

可恢复性的错误：

如遇到在leader的选举、网络的抖动等这些异常时，如果我们在这个时候配置的retries大于0的，也就是可以进行重试操作，那么等到leader选举完成后、网络稳定后，这些异常就会消息，错误也就可以恢复，数据再次重发时就会正常发送到broker端。需要注意retries(重试)之间的时间间隔，以确保在重试时可恢复性错误都已恢复。

不可恢复性的错误：

如：超过了发送消息的最大值(max.request.size)时，这种错误是不可恢复的，如果不做处理，那么数据就会丢失，因此我们需要注意在发生异常时把这些消息写入到DB、缓存本地文件中等等，把这些不成功的数据记录下来，等错误修复后，再把这些数据发送到broker端。

我们上面讲了2个配置项的作用，下面结合实际场景如何使用

3、如何选取

1.高可用型

配置：acks = all，retries > 0 retry.backoff.ms=100(毫秒) (并根据实际情况设置retry可能恢复的间隔时间)

优点：这样保证了producer端每发送一条消息都要成功，如果不成功并将消息缓存起来，等异常恢复后再次发送。

缺点：这样保证了高可用，但是这会导致集群的吞吐量不是很高，因为数据发送到broker之后，leader要将数据同步到fllower上，如果网络带宽、不稳定等情况时，ack响应时间会更长

2.折中型

配置：acks = 1 retries > 0 retries 时间间隔设置 (并根据实际情况设置retries可能恢复的间隔时间)

优点：保证了消息的可靠性和吞吐量，是个折中的方案

缺点：性能处于2者中间

3.高吞吐型

配置：acks = 0

优点：可以相对容忍一些数据的丢失，吞吐量大，可以接收大量请求

缺点：不知道发送的消息是 否成功

二、consumer端是如何保证数据不丢失的

---

1、consumer端的配置项

group.id: consumer group 分组的一个id

消费者隶属的消费组名称。在kafka中只允许消息只能被某个组里面的一个consumer端消费，如果为空，则会报异常。

对于一个新的consumer加入到消费时，肯定会隶属于哪个组，只有这样才能消费数据

auto.offset.reset = earliest(最早) /latest(最晚)

从何处开始进行消费

当一个新加入的consumer要进行消费数据，如果这个consumer是做数据分析工作的，是需要以前的历史数据那就需要从最早的位置消费数据，如果仅仅是查看消费情况，那可以从最晚位置开始消费数据

enable.auto.commit = true/false(默认true)

是否开启自动提交消费位移的功能,默认开启.

当设置为true时，意味着由kafka的consumer端自己间隔一定的时间会自动提交offset，如果设置成了fasle，也就是由客户端(自己写代码)来提交，那就还得控制提交的时间间隔auto.commit.interval.ms

auto.commit.interval.ms

当enable.auto.commit设置为true时才生效，表示开启自动提交消费位移功能时自动提交消费位移的时间间隔。

2、consumer端的配置策略

在consumer消费阶段，对offset的处理，关系到是否丢失数据，是否重复消费数据，因此，我们把处理好offset就可以做到exactly-once && at-least-once(只消费一次)数据。

当enable.auto.commit=true时

表示由kafka的consumer端自动提交offset,当你在pull(拉取)30条数据，在处理到第20条时自动提交了offset,但是在处理21条的时候出现了异常，当你再次pull数据时，由于之前是自动提交的offset，所以是从30条之后开始拉取数据，这也就意味着21-30条的数据发生了丢失。

当enable.auto.commit=false时

由于上面的情况可知自动提交offset时，如果处理数据失败就会发生数据丢失的情况。那我们设置成手动提交。

当设置成false时，由于是手动提交的，可以处理一条提交一条，也可以处理一批，提交一批，由于consumer在消费数据时是按一个batch来的，当pull了30条数据时，如果我们处理一条，提交一个offset，这样会严重影响消费的能力，那就需要我们来按一批来处理，或者设置一个累加器，处理一条加1，如果在处理数据时发生了异常，那就把当前处理失败的offset进行提交(放在finally代码块中)注意一定要确保offset的正确性，当下次再次消费的时候就可以从提交的offset处进行再次消费。

3、comsumer 的应用场景

1.一直commit offset的处理

假如poll了100条数据，每处理1条，commit offset一次，这样会严重影响性能，在处理的时候设置1个计数器(或累加器)，按一批来提交，但要确保提交offset的准确性

2.rebalance的影响

在处理数据时，有2种情况会发生，一种情况是处理了一半的时候，发生了rebalance，但是offset还没有来得及提交，另一种情况是rebalance发生后，重新分配了offset,在这种情况时会发生错误。

3.消息处理错误时的处理

假如consumer在处理数据的时候失败了，那么可以把这条数据给缓存起来，可以是redis、DB、file等，也可以把这条消息存入专门用于存储失败消息的topic中，让其它的consumer专门处理失败的消息。

4.处理消息的时间过长

假如poll一批100条消息的时间是1秒钟，但是在每处理1条需要花费1秒钟，这样来说极其影响消费能力，那我们可以把100条消息放到1个线程池中处理。这里特别特别注意，由于线程池的处理行为是并行的，所以要做对offset的判断。这里先说正常情况，如果消息都能被正常处理，那么会提交1个offset，并把这个offset存起来，假如此时又提交了1个offset,把2个offset相对比，哪个大把哪个存起来并做提交。如果消息处理发生了错误，我们在前面讲过，把这个错误消息发送到专门处理错误的topic中，让专门的consumer来处理。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

感受：

其实我投简历的时候，都不太敢投递阿里。因为在阿里一面前已经过了字节的三次面试，投阿里的简历一直没被捞，所以以为简历就挂了。

特别感谢一面的面试官捞了我，给了我机会，同时也认可我的努力和态度。对比我的面经和其他大佬的面经，自己真的是运气好。别人8成实力，我可能8成运气。所以对我而言，我要继续加倍努力，弥补自己技术上的不足，以及与科班大佬们基础上的差距。希望自己能继续保持学习的热情，继续努力走下去。

也祝愿各位同学，都能找到自己心动的offer。

分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

[外链图片转存中…(img-rs6NZlYf-1713212164728)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！