Fork me on GitHub

面试官:Leader崩溃Follower不够新怎么办?

这是一道非常经典的 Kafka 问题,是关于 Leader 在“异常”情况下的选举问题。

背景

我们知道 Kafka 中的 Partition(分区)是存储消息的最终介质,但 Partition 又有两种分类:

  1. Leader Partition:主分区,负责数据写入和读取。
  2. Follower Partition:副本分区,用于数据备份和主节点宕机之后的分区选举,保证了 Kafka 服务的高可用。

如下图所示:
image.png
其中,Leader Partition 是用来处理生产者和消费者请求的,而 Follower Partition 是用来保证 Kafka 集群的高可用的,也就是当 Leader Partition 宕机之后,会通过某种算法将其中一个 Follower Partition 升级为 Leader Partition 继续运行。

不同步的 Follower 节点

在分布式系统下,数据一致性问题是一个令人头疼的问题,那么这个问题在 Kafka Leader Partition 和 Follower Partition 中也存在,例如以下场景:
image.png
也就是说,Follower Partition 还未从 Leader Partition 中同步到最新的数据,Leader Partition 就突然宕机了,这就产生了不同的 Follower 节点了。

小知识点:数据一致性问题是指在一个系统中,不同部分的数据在逻辑上应该保持一致,但实际情况却出现了矛盾或不匹配的现象。

那问题来了,如果有不同步的 Follower Partition 要升级为 Leader 会发生什么问题?

升级 VS 不升级

当出现不同步的 Follower Partition,而 Leader Partition 有意外宕机的场景,此时我们有两种选择:

  1. 将不同步的 Follower 节点升级为 Leader 节点:但这样就会造成数据丢失的问题,但好处是此时集群可以继续运行。
  2. 不同步的 Follower 不自动升级 Leader 节点:等待原 Leader 恢复再继续运行,此时不会导致数据丢失,但可能要等待很久才能恢复 Kafka 服务的正常运行,因为 Leader 宕机可能要更新内存芯片之后才能运行,而这个时间是比较久的。

所以,不同步的 Follower 节点是升级为 Leader 或不升级为 Leader 都有其优点和缺点。

使用者的选择权

而在这种情况下,Kafka 就把这个选择权给使用者了,此时我们可以通过配置 Broker(或集群)的“unclean.leader.election.enable”属性来决定到底要不要升级不同步的 Follower 节点为 Leader 节点,这个属性有以下两个值可以设置:

  1. true:如果此属性设置为 true,那么即使是不完全同步的 Follower Partition 也会升级为 Leader,此时牺牲了一定的数据一致性(数据丢失风险),保证了 Kafka 服务的高可用。
  2. false:如果此属性设置为 false,就表示不会将不完全同步的 Follower Partition 升级为 Leader,会等待原 Leader 重新上线之后才能继续运行 Kafka 服务。此时保证了数据的一致性,但牺牲了 Kafka 服务的可用性。

unclean.leader.election.enable 的默认值为 true。

因此,如果是对数据丢失不敏感的系统可以使用 unclean.leader.election.enable=true,如果对数据丢失敏感的,例如银行系统等可以使用 unclean.leader.election.enable=false 保证数据的一致性。

课后思考

说说 Follower 升级为 Leader 的选举算法和执行流程?

本文已收录到我的面试小站 www.javacn.site,其中包含的内容有:Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。

posted @ 2024-08-27 12:11  磊哥|www.javacn.site  阅读(3)  评论(0编辑  收藏  举报