【年后跳槽必看篇 - 非广告】Kafka 核心知识点 - 第四章

Kafka 高水位了解吗，为什么 Kafka 需要 Leader Epoch

什么是 Kafka 的高水位

所谓高水位(HW，High Watermark)是 Kafka 中一个重要的概念，主要是用于管理消费者的进度和保证数据的可靠性。

高水位标识了一个特定的消息偏移量（offset），即一个分区中已经提交消息的最高偏移量（offset）【已提交指的是 ISRs 中的所有副本都记录了这条信息】，消费者只能拉去到这个 offset 之前的消息。消费者可以通过跟踪高水位来确定自己的消费位置

Kafka 高水位的作用

在 Kafka 中，高水位（HW）主要有一下两个作用：

1. 消费者进度管理：消费者可以通过记录上一次消费的偏移量，然后将其与分区的高水位进行比较，来确定自己的消费进度。消费者可以在高水位对比之后继续消费新的消息，确保不会错过任何已提交的消息。这样，消费者可以按照自己的节奏进行消费，不受其他消费者的影响

2. 数据的可靠性：高水位还可用于保证数据的可靠性。在 Kafka 中，只有消息被写入主副本（Leader Replica）并被所有同步副本（In Sync Replicas ,ISR）确认后，才被认为是已提交的消息。高水位表示已经被提交的消息边界。之后高水位之前的消息才能被认为时已经被确认的，其它消息可能会因为副本故障或其他原因而丢失

在 Kafka 中还有一个概念，叫做 LEO（Log End Offset），它是日志最后的消息偏移量。他表示当前日志文件中下一条待写入消息的 offset。

当消费者消费消息时，它可以使用高水位作为参照点，之消费高水位之前的消息，以确保消费的时已经被确认的消息，从而保证数据的可靠性。如下图，只消费 offset 为 6 之前的消息。

什么是 Leader Epoch

在 Kafka 中，每个分区都有一个 Leader 副本和多个 Follewer 副本。当 Leader 副本发生故障时，Kafka 会选择一个新的 Leader 副本。这个切换过程中，需要保证数据的一致性，即新的 Leader 副本必须具有和旧的 Leader 副本一样的消息顺序。

• 为了实现这个目标,Kafka 引入了Leader Epoch的概念。Leader Epoch 是一个递增的整数，每次副本切换时都会增加。它用于标识每个 Leader 副本的任期。

• 同时，每个副本都会为会自己的 Leader Epoch 记录。它记录副本所属的分区在不同 Leader 副本之间切换时的任期。

• 在副本切换过程中，新的 Leader 会检查旧 Leader 副本的 Leader Epoch 和高水位。只有当旧 Leader 和 Leader Epoch 小于等于 Leader 副本的 Leader Epoch，并且旧 Leader 副本的高水位小于等于新 Leader 副本的高水位时，新 Leader 副本才会接受旧 Leader 副本的数据

• 通过 Leader Epoch 和高水位的验证，Kafka 可以避免新的 Leader 副本接收旧 Leader 副本之后的消息，从而避免数据回滚。只有那些在旧 Leader 副本的 Leader Epoch 和高水位之前的消息才会被 Leader 副本接受。

Kafka Leader Epoch 的过程

每个 Partition 都有一个初始的 leader Epoch，通常为 0；当 Leader 副本发生故障时或者需要进行切换时，Kafka 会触发副本切换的过程；副本切换过程中，Kafka 会从 ISR（In-Sync Replicas，同步副本）中选择一个新的 Follower 副本作为新的 Leader 副本；新的 Leader 副本会增加自己的 Leader Epoch，使其大于之前的 Leader Epoch。这表示进入了一个新的任期；新的 Leader 副本会验证旧 Leader 副本的状态以确保数据一致性的问题。它会检查旧 Leader 的 Leader Epoch 和高水位；如果旧 Leader 副本的 Leader Epoch 小于等于新 Leader 副本的 Leader Epoch，并且 Leader 副本的高水位小于等于新 Leader 副本的高水位，则验证通过；一旦验证通过，新的 Leader 副本会开始从 ISR 中的一部分副本复制数据，以确保新 Leader 上的数据与旧 Leader 一致；一旦新的 Leader 副本复制了旧 Leader 副本的所有数据，并达到了与旧 Leader 副本相同的高水位，副本切换过程就完成了。

Kafka 的 ISR 机制

ISR，就是 In-Sync Replicas 同步副本的意思。

在 Kafka 中，每个 Topic、Partition 可以有多个副本（replica）。ISR 是与主副本（Leader Replica）保持同步的副本集合。ISR 机制就是用于确保数据的可靠性和一致性。

当消息被写入 Kafka 的分区时，它首先会被写入 Leader，然后 Leader 将消息复制给 ISR 中的所有副本。只有当 ISR 中所有副本都成功地接收到并确认了消息后，主副本才会认为消息已经成功提交。这种机制确保了数据可靠性和一致性

了解 ISR 的列表维护了解嘛

在 Kafka 中，ISR（In-Sync Replicas）列表的维护是通过副本状态和配置参数来进行的。具体的 ISR 列表维护机制在不同的 Kafka 版本中有所变化。

0.9.x 版本之前

在 0.9.x 之前的版本，Kafka 有一个核心的参数：replica.lag.max.messages，表示如果 Follower 落后 Leader 的消息数量超过了这个参数值，就认为 Follower 就会从 ISR 列表里移除。

但是，基于replica.lag.max.message这种实现，在瞬间高并发访问的情况下会有问题：比如 Leader 瞬间接收到几万条消息，然后所有 Follower 还没来得及同步过去，此时所有 follower 都会被踢出 ISR 列表。

0.9.x 版本之后

Kafka 从 0.9.x 版本之后，引入了replica.lag.max.ms参数，表示如果某个 Follower 的 LEO（latest end offset）一直落后 Leader 超过了 10 秒，那么才会被 ISR 列表移除。

这样的话，即使出现瞬间流量，导致 Follower 落后很多数据，但是只要在限定的时间内尽快追上来就行了。

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或关注微信公众号【码上遇见你】。

好了，本章节到此告一段落。希望对你有所帮助，祝学习顺利。