【kafka技术篇】kafka原来是这样丢的数据

🍬 博主介绍

👨‍🎓 博主介绍：大家好，我是淼淼_喵 ，很高兴认识大家~

✨主攻领域：【大数据开发】【数据仓库】 【ETL】 【数据分析】【面试分析】

🎉点赞➕评论➕收藏 == 养成习惯（一键三连）😋

🎉欢迎关注💗一起学习👍一起讨论⭐️一起进步📝欢迎评论

🙏作者水平有限，欢迎各位大佬指点，相互习进步！

kafka相关问题

每个 Leader 会动态维护一个 ISR 列表，该列表里存储的是和 Leader 基本同步的 Follower。

如果有 Follower 由于网络、GC 等原因而没有向 Leader 发起拉取数据请求，此时 Follower 相对于 Leader 是不同步的，则会被踢出 ISR 列表。

所以说，ISR 列表中的 Follower 都是跟得上 Leader 的副本。

一个节点宕机后 Leader 的选举规则是什么？分布式相关的选举规则有很多，像 Zookeeper 的 Zab、Raft、Viewstamped Replication、微软的 PacificA 等。

而 Kafka 的 Leader 选举思路很简单，基于我们上述提到的 ISR 列表，当宕机后会从所有副本中顺序查找，如果查找到的副本在 ISR 列表中，则当选为 Leader。

另外还要保证前任 Leader 已经是退位状态了，否则会出现脑裂情况（有两个Leader）。

怎么保证？Kafka 通过设置了一个 Controller 来保证只有一个 Leader。

Ack 参数决定了可靠程度

另外，这里补充一个面试考 Kafka 高可用必备知识点：request.required.asks 参数。

Asks 这个参数是生产者客户端的重要配置，发送消息的时候就可设置这个参数。

该参数有三个值可配置：

• 0

• 1

• All

第一种是设为 0，意思是生产者把消息发送出去之后，之后这消息是死是活咱就不管了，有那么点发后即忘的意思，说出去的话就不负责了。不负责自然这消息就有可能丢失，那就把可用性也丢失了。

第二种是设为 1，意思是生产者把消息发送出去之后，这消息只要顺利传达给了 Leader，其他 Follower 有没有同步就无所谓了。

存在一种情况，Leader 刚收到了消息，Follower 还没来得及同步 Broker 就宕机了，但生产者已经认为消息发送成功了，那么此时消息就丢失了。

注意，设为 1 是 Kafka 的默认配置！！！可见 Kafka 的默认配置也不是那么高可用，而是对高可用和高吞吐量做了权衡折中。

第三种是设为 All（或者 -1），意思是生产者把消息发送出去之后，不仅 Leader 要接收到，ISR 列表中的 Follower 也要同步到，生产者才会任务消息发送成功。

进一步思考，Asks=All 就不会出现丢失消息的情况吗？答案是否。

当 ISR 列表只剩 Leader 的情况下，Asks=All 相当于 Asks=1，这种情况下如果节点宕机了，还能保证数据不丢失吗？

因此只有在 Asks=All 并且有 ISR 中有两个副本的情况下才能保证数据不丢失。