一次关于kafka数据丢失场景的激烈讨论...

网友投稿 919 2022-05-28

百分之80的同学都理解错了的小知识点…

问题描述

最近彦祖发现,有不少同学 对

acks

一次关于kafka数据丢失场景的激烈讨论...

min.insync.replicas

的配置存在不少误解.

刚好拿一个同学的问题,来好好说明一下

根据上面提的几个问题, 整理一下几个知识点

acks = all的概念是什么?

min.insync.replicas 是怎么用的?

什么情况下会发生数据丢失的风险?

问题解答

acks = all

acks=0

: 生产者不会等待服务器的任何确认, 该记录将立即添加到Socket Buffer Pool 并被视为已发送,这种情况,不保证发送成功,可能会丢失数据。

acks=1

: 这个保证了至少Leader副本会将数据写入到本地日志中,不管其他副本是否写入。所以当Leader同步成功之后,还没有来得及同步给Follower副本就宕机了。那么就会丢失数据。

acks=-1/all

: 这个确保

ISR中的所有同步副本列表

中都确认写入了数据之后,才会视为发送成功, 所以这个配置可以提供最高级的数据可靠性的保证, 不会丢失数据。

但是,就算我们设置了

acks=-1/all

, 并且也有3个副本, 但是这个时候 Follower副本都没有加入到ISR的集合中, ISR 只剩下了一个 Leader 副本。如果这个Leader宕机了, 是不是可能会造成分区不可用或者数据丢失的情况了 !

那么这种情况是不是就跟 ack=1的情况一样了, 相当于只保证了Leader写入了数据。还是达不到高可靠性。

那么,怎么解决这个问题呢?

是不是只需要让 ISR 里面的同步副本 >1 就行了, 只有一个挂掉了,还有1个作为备份。

最小同步副本数 min.insync.replicas

最小同步副本数, 表示的是 ISR 列表里面最小的个数。这个是跟

acks=-1/all

配套使用的,默认是=1。

这个配置再加上上面的

acks=-1/all

是不是就可以设置高可靠性了

特别需要注意:这个配置是用来设置同步副本个数的下限的, 并不是只有 min.insync.replicas 个副本同步成功就返回ack。

只要你

acks=-1/all

就意味着你ISR里面的副本必须都要同步成功。

读者问题解答

理解清楚了上面的知识点,那么这位朋友的问题应该就可以回答了吧。

问题:Kafka副本数设置为3,min.insync.replicas=2 ,此时AR={1,2,3} ISR={3,2,1} 0分区的leader为3,假设当前写入3成功,1和3同步成功,满足ack=all 返回客户端写入成功,然后leader3宕机,选举2为leader,假设此时2刚好没同步,是不是会出现数据丢失风险呢?

问题扩展

当Broker单副本, acks=all 的情况下

Broker正常关机,会不会导致消息丢失

Broker异常crash, 会不会导致消息丢失

物理机正常关机, 会不会导致消息丢失

物理机异常掉电关机,会不会导致消息丢失

群友见解 :

彦祖拙见:

不会丢

不会丢/重复数据

①. 要么他没有成功写入数据,但是这个时候不会返回ack,那么producer没有收到ack,则会尝试重发,所以这不属于丢书数据。

②. 它成功写入了数据, 但是还没有来得及返回ack, producer会尝试重发, 等重启之后 可能会收到重复消息

③. 它成功写入数据, ack也返回了,不会丢失数据。

注意:这里说的写入成功,是写入内存中 pagecache中

不会丢

会丢

思考上面问题的一个很重要的知识点:

kafka在写数据的时候 默认是依赖操作系统来刷盘的。

kafka认为写入成功不是写入磁盘成功,而是写到到PageCache中。 所以 ,只要不是 服务器掉电,PageCache中的内存数据就还在,就不会丢数据

欢迎大家,一起在评论区参与讨论, 想要进群的小伙伴可以加哈!

我也会把我的见解写在评论区!

Kafka 大数据 运维

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:【STM32平衡小车】APP调试协议及代码分析
下一篇:【Python编程创造营·第二期】最终积分排行榜和最终考核成绩公示!
相关文章