在 Kafka 中，高水位的作用主要有 2 個。
- 定義消息可見性，即用來標識分區下的哪些消息是可以被消費者消費的。
- 幫助 Kafka 完成副本同步。
下面這張圖展示了多個與高水位相關的 Kafka 術語。我來詳細解釋一下圖中的內容，同時澄清一些常見的誤區。
位移值等于高水位的消息也屬于未提交消息。也就是說，高水位上的消息是不能被消費者消費的。
Log End Offset，簡寫是 LEO。它表示副本寫入下一條消息的位移值。
介于高水位和 LEO 之間的消息就屬于未提交消息。這也從側面告訴了我們一個重要的事實，那就是：同一個副本對象，其高水位值不會大于 LEO 值。
什么叫與 Leader 副本保持同步。判斷的條件有兩個。
- 該遠程 Follower 副本在 ISR 中。
- 該遠程 Follower 副本 LEO 值落后于 Leader 副本 LEO 值的時間，不超過 Broker 端參數 replica.lag.time.max.ms 的值。如果使用默認值的話，就是不超過 10 秒
副本同步機制解析
當生產者發送一條消息時，Leader 和 Follower 副本對應的高水位是怎么被更新的呢？我給出了一些圖片，我們一一來看。
首先是初始狀態。下面這張圖中的 remote LEO 就是剛才的遠程副本的 LEO 值。在初始狀態時，所有值都是 0。
當生產者給主題分區發送一條消息后，狀態變更為：
此時，Leader 副本成功將消息寫入了本地磁盤，故 LEO 值被更新為 1。
Follower 再次嘗試從 Leader 拉取消息。和之前不同的是，這次有消息可以拉取了，因此狀態進一步變更為：
這時，Follower 副本也成功地更新 LEO 為 1。此時，Leader 和 Follower 副本的 LEO 都是 1，但各自的高水位依然是 0，還沒有被更新。它們需要在下一輪的拉取中被更新，如下圖所示：
在新一輪的拉取請求中，由于位移值是 0 的消息已經拉取成功，因此 Follower 副本這次請求拉取的是位移值 =1 的消息。Leader 副本接收到此請求后，更新遠程副本 LEO 為 1，然后更新 Leader 高水位為 1。做完這些之后，它會將當前已更新過的高水位值 1 發送給 Follower 副本。Follower 副本接收到以后，也將自己的高水位值更新成 1。至此，一次完整的消息同步周期就結束了。事實上，Kafka 就是利用這樣的機制，實現了 Leader 和 Follower 副本之間的同步。
Leader Epoch 登場
我們知道，Follower 副本的高水位更新需要一輪額外的拉取請求才能實現。如果把上面那個例子擴展到多個 Follower 副本，情況可能更糟，也許需要多輪拉取請求。也就是說，Leader 副本高水位更新和 Follower 副本高水位更新在時間上是存在錯配的。這種錯配是很多“數據丟失”或“數據不一致”問題的根源。基于此，社區在 0.11 版本正式引入了 Leader Epoch 概念，來規避因高水位更新錯配導致的各種不一致問題。
所謂 Leader Epoch，我們大致可以認為是 Leader 版本。它由兩部分數據組成。
- Epoch。一個單調增加的版本號。每當副本領導權發生變更時，都會增加該版本號。小版本號的 Leader 被認為是過期 Leader，不能再行使 Leader 權力。
- 起始位移（Start Offset）。Leader 副本在該 Epoch 值上寫入的首條消息的位移。
我舉個例子來說明一下 Leader Epoch。假設現在有兩個 Leader Epoch<0, 0> 和 <1, 120>，那么，第一個 Leader Epoch 表示版本號是 0，這個版本的 Leader 從位移 0 開始保存消息，一共保存了 120 條消息。之后，Leader 發生了變更，版本號增加到 1，新版本的起始位移是 120。
Kafka Broker 會在內存中為每個分區都緩存 Leader Epoch 數據，同時它還會定期地將這些信息持久化到一個 checkpoint 文件中。當 Leader 副本寫入消息到磁盤時，Broker 會嘗試更新這部分緩存。如果該 Leader 是首次寫入消息，那么 Broker 會向緩存中增加一個 Leader Epoch 條目，否則就不做更新。這樣，每次有 Leader 變更時，新的 Leader 副本會查詢這部分緩存，取出對應的 Leader Epoch 的起始位移，以避免數據丟失和不一致的情況。
接下來，我們來看一個實際的例子，它展示的是 Leader Epoch 是如何防止數據丟失的。請先看下圖。
我稍微解釋一下，單純依賴高水位是怎么造成數據丟失的。開始時，副本 A 和副本 B 都處于正常狀態，A 是 Leader 副本。某個使用了默認 acks 設置的生產者程序向 A 發送了兩條消息，A 全部寫入成功，此時 Kafka 會通知生產者說兩條消息全部發送成功。
現在我們假設 Leader 和 Follower 都寫入了這兩條消息，而且 Leader 副本的高水位也已經更新了，但 Follower 副本高水位還未更新——這是可能出現的。還記得吧，Follower 端高水位的更新與 Leader 端有時間錯配。倘若此時副本 B 所在的 Broker 宕機，當它重啟回來后，副本 B 會執行日志截斷操作，將 LEO 值調整為之前的高水位值，也就是 1。這就是說，位移值為 1 的那條消息被副本 B 從磁盤中刪除，此時副本 B 的底層磁盤文件中只保存有 1 條消息，即位移值為 0 的那條消息。
當執行完截斷操作后，副本 B 開始從 A 拉取消息，執行正常的消息同步。如果就在這個節骨眼上，副本 A 所在的 Broker 宕機了，那么 Kafka 就別無選擇，只能讓副本 B 成為新的 Leader，此時，當 A 回來后，需要執行相同的日志截斷操作，即將高水位調整為與 B 相同的值，也就是 1。這樣操作之后，位移值為 1 的那條消息就從這兩個副本中被永遠地抹掉了。這就是這張圖要展示的數據丟失場景。
嚴格來說，這個場景發生的前提是Broker 端參數 min.insync.replicas 設置為 1。此時一旦消息被寫入到 Leader 副本的磁盤，就會被認為是“已提交狀態”，但現有的時間錯配問題導致 Follower 端的高水位更新是有滯后的。如果在這個短暫的滯后時間窗口內，接連發生 Broker 宕機，那么這類數據的丟失就是不可避免的。
現在，我們來看下如何利用 Leader Epoch 機制來規避這種數據丟失。我依然用圖的方式來說明。
場景和之前大致是類似的，只不過引用 Leader Epoch 機制后，Follower 副本 B 重啟回來后，需要向 A 發送一個特殊的請求去獲取 Leader 的 LEO 值。在這個例子中，該值為 2。當獲知到 Leader LEO=2 后，B 發現該 LEO 值不比它自己的 LEO 值小，而且緩存中也沒有保存任何起始位移值 > 2 的 Epoch 條目，因此 B 無需執行任何日志截斷操作。這是對高水位機制的一個明顯改進，即副本是否執行日志截斷不再依賴于高水位進行判斷。
現在，副本 A 宕機了，B 成為 Leader。同樣地，當 A 重啟回來后，執行與 B 相同的邏輯判斷，發現也不用執行日志截斷，至此位移值為 1 的那條消息在兩個副本中均得到保留。后面當生產者程序向 B 寫入新消息時，副本 B 所在的 Broker 緩存中，會生成新的 Leader Epoch 條目：[Epoch=1, Offset=2]。之后，副本 B 會使用這個條目幫助判斷后續是否執行日志截斷操作。這樣，通過 Leader Epoch 機制，Kafka 完美地規避了這種數據丟失場景。
