关于kafka数据丢失场景的一次激烈讨论.... |文末送书
Posted 石臻臻的杂货铺
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于kafka数据丢失场景的一次激烈讨论.... |文末送书相关的知识，希望对你有一定的参考价值。
问题描述
最近彦祖发现,有不少同学 对 acks 和 min.insync.replicas 的配置存在不少误解.
刚好拿一个同学的问题,来好好说明一下
根据上面提的几个问题, 整理一下几个知识点
acks = all的概念是什么？min.insync.replicas是怎么用的？- 什么情况下会发生数据丢失的风险？
为更好的阅读体验,和及时的勘误
请访问原文链接：acks和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数据丢失场景的一次激烈讨论.... |文末送书的主要内容，如果未能解决你的问题，请参考以下文章
用ZooKeeper真的low吗？上千个节点场景配置服务方案大讨论 - 高可用架构系列