这是一道非常经典的 Kafka 问题,是关于 Leader 在“异常”情况下的选举问题。
背景
我们知道 Kafka 中的 Partition(分区)是存储消息的最终介质,但 Partition 又有两种分类:
- Leader Partition:主分区,负责数据写入和读取。
- Follower Partition:副本分区,用于数据备份和主节点宕机之后的分区选举,保证了 Kafka 服务的高可用。
如下图所示:
其中,Leader Partition 是用来处理生产者和消费者请求的,而 Follower Partition 是用来保证 Kafka 集群的高可用的,也就是当 Leader Partition 宕机之后,会通过某种算法将其中一个 Follower Partition 升级为 Leader Partition 继续运行。
不同步的 Follower 节点
在分布式系统下,数据一致性问题是一个令人头疼的问题,那么这个问题在 Kafka Leader Partition 和 Follower Partition 中也存在,例如以下场景:
也就是说,Follower Partition 还未从 Leader Partition 中同步到最新的数据,Leader Partition 就突然宕机了,这就产生了不同的 Follower 节点了。
这边整理了一份核心面试笔记包括了:Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题
需要全套面试笔记的【点击此处即可】免费获取
小知识点:数据一致性问题是指在一个系统中,不同部分的数据在逻辑上应该保持一致,但实际情况却出现了矛盾或不匹配的现象。
那问题来了,如果有不同步的 Follower Partition 要升级为 Leader 会发生什么问题?
升级 VS 不升级
当出现不同步的 Follower Partition,而 Leader Partition 有意外宕机的场景,此时我们有两种选择:
- 将不同步的 Follower 节点升级为 Leader 节点:但这样就会造成数据丢失的问题,但好处是此时集群可以继续运行。
- 不同步的 Follower 不自动升级 Leader 节点:等待原 Leader 恢复再继续运行,此时不会导致数据丢失,但可能要等待很久才能恢复 Kafka 服务的正常运行,因为 Leader 宕机可能要更新内存芯片之后才能运行,而这个时间是比较久的。
所以,不同步的 Follower 节点是升级为 Leader 或不升级为 Leader 都有其优点和缺点。
使用者的选择权
而在这种情况下,Kafka 就把这个选择权给使用者了,此时我们可以通过配置 Broker(或集群)的“unclean.leader.election.enable”属性来决定到底要不要升级不同步的 Follower 节点为 Leader 节点,这个属性有以下两个值可以设置:
- true:如果此属性设置为 true,那么即使是不完全同步的 Follower Partition 也会升级为 Leader,此时牺牲了一定的数据一致性(数据丢失风险),保证了 Kafka 服务的高可用。
- false:如果此属性设置为 false,就表示不会将不完全同步的 Follower Partition 升级为 Leader,会等待原 Leader 重新上线之后才能继续运行 Kafka 服务。此时保证了数据的一致性,但牺牲了 Kafka 服务的可用性。
unclean.leader.election.enable 的默认值为 true。
因此,如果是对数据丢失不敏感的系统可以使用 unclean.leader.election.enable=true,如果对数据丢失敏感的,例如银行系统等可以使用 unclean.leader.election.enable=false 保证数据的一致性。