这是一道非常经典的 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 节点了。
小知识点：数据一致性问题是指在一个系统中，不同部分的数据在逻辑上应该保持一致，但实际情况却出现了矛盾或不匹配的现象。
那问题来了，如果有不同步的 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 保证数据的一致性。
课后思考
说说 Follower 升级为 Leader 的选举算法和执行流程？
本文已收录到我的面试小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。
