面试官：Leader崩溃Follower不够新怎么办？

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

背景

我们知道 Kafka 中的 Partition（分区）是存储消息的最终介质，但 Partition 又有两种分类：

1. Leader Partition：主分区，负责数据写入和读取。
2. 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 节点了。

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

那问题来了，如果有不同步的 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、设计模式、消息队列等模块。