Kafka选举机制及数据丢失情况分析

1 首领选举

2 数据损失配置及情况分析

2.1 不完全首领选举

unclean.leader.election 只能在broker级别（实际上是在集群范围内）进行配置，它的默认值是true 。我们之前提到过，当分区首领不可用时，一个同步副本会被选为新首领。 如果在选举过程中没有丢失数据，也就是说提交的数据同时存在于所有的同步副本上，那么这个选举就是“完全”的。但如果在首领不可用时其他副本都是不同步的，我们该怎么办呢？
这种情况会在以下两种场景里出现。
问题：
• 分区有 3 个副本，其中的两个跟随者副本不可用（比如有两个 broker 发生崩愤）。这个
时候，如果生产者继续往首领写入数据，所有消息都会得到确认井被提交（因为此时首
领是唯一的同步副本）。现在我们假设首领也不可用 了（又一个 broker 发生崩愤），这
个时候，如果之前的一个跟随者重新启动，它就成为了分区的唯一不同步副本 。
• 分区有 3 个副本，因为网络问题导致两个跟随者副本复制消息滞后，所以尽管它们还在
复制消息，但已经不同步了。首领作为唯一的同步副本继续接收消息。这个时候，如果
首领变为不可用，另外两个副本就再也无桂变成同步的了 。
对于这两种场景 ，我们要作出一个两难的选择。
解决办法：
• 如果不同步的副本不能被提升为新首领，那么分区在旧首领（最后一个同步副本）恢复之前是不可用的。有时候这种状态会持续数小时（比如更换内存芯片）。
• 如果不同步的副本可以被提升为新首领，那么在这个副本变为不同步之后写入旧首领的消息、会全部丢失，导致数据不一致。为什么会这样呢？假设在副本0和副本l不可用时，偏移量100-200的消息被写入副本 2（首领）。现在副本2变为不可用的，而副本 0 变为可用的。副本 0 只包含偏移量O～100的消息，不包含偏移量100～200的悄息。如果我们允许副本0成为新首领，生产者就可以继续写人数据，悄费者可以继续读取数据。于是，新首领就有了偏移量 100～200 的新梢息。这样，部分消费者会读取到偏移量100～200的旧消息，部分消费者会读取到偏移量 100～200 的新消息，还有部分消费者读取的是二者的混合。这样会导致非常不好的结果，比如生成不准确的报表。另外，副本2可能会重新变为可用，并成为新首领的跟随者。这个时候，它会把比当前首领旧的消息全部删除，而这些消息对于所有消费者来说都是不可用的。

2.2 最少同步副本

在主题级别和 broker 级别上，这个参数都叫 min.insync.replicas 。
我们知道，尽管为一个主题配置了3个副本，还是会出现只有一个同步副本的情况。如果这个同步副本变为不可用，我们必须在可用性和一致性之间作出选择一一这是一个两难的选择。 根据Kafka对可靠性保证的定义，消息只有在被写入到所有同步副本之后才被认为是已提交的。但如果这里的“所有副本”只包含一个同步副本，那么在这个副本变为不可用时，数据就会丢失。
如果要确保已提交的数据被写入不止一个副本，就需要把最少同步副本数量设置为大一点的值。对于一个包含 3 个副本的主题，如果min.insync.replicas被设为 2，那么至少要存在两个同步副本才能向分区写入数据。如果3个副本都是同步的，或者其中一个副本变为不可用，都不会有什么问题。不过，如果有两个副本变为不可用，那么 broker 就会停止接受生产者的请求。尝试发送数据的生产者会收到 NotEnoughRepli.casExcepti.on 异常。消费者仍然可以继续读取已有的数据。实际上，如果使用这样的配置，那么当只剩下一个同步副本时，它就变成只读了，这是为了避免在发生不完全选举时数据的写入和读取出现非预期的行为。为了从只读状态中恢复，必须让两个不可用分区中的一个重新变为可用的（比如重启broker），并等待它变为同步的。

2.3 几种发送场景消息丢失的场景

1. 网络异常:acks设置为0时，不和Kafka集群进行消息接受确认，当网络发生异常等情况时，存在消息丢失的可能；

2. 客户端异常:异步发送时，消息并没有直接发送至Kafka集群，而是在Client端按一定规则缓存并批量发送。在这期间，如果客户端发生死机等情况，都会导致消息的丢失；

3. 缓冲区满了:异步发送时，Client端缓存的消息超出了缓冲池的大小，也存在消息丢失的可能；

4. Leader副本异常:acks设置为1时，Leader副本接收成功，Kafka集群就返回成功确认信息，而Follower副本可能还在同步。这时Leader副本突然出现异常，新Leader副本(原Follower副本)未能和其保持一致，就会出现消息丢失的情况；