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

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

如下图所示：

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

在分布式系统下，数据一致性问题是一个令人头疼的问题，那么这个问题在 Kafka Leader Partition 和 Follower Partition 中也存在，例如以下场景：

也就是说，Follower Partition 还未从 Leader Partition 中同步到最新的数据，Leader Partition 就突然宕机了，这就产生了不同的 Follower 节点了。

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

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

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

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

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