高水位
在分區高水位以下的消息被認為是已提交消息。kafka中，分區的高水位就是其 Leader 副本的高水位。
作用
- 定義消息可見性，即用來標識分區下的哪些消息是可以被消費者消費的。
- 幫助 Kafka 完成副本同步。
LEO（Log End Offset）表示副本寫入下一條消息的位移值。
高水位更新機制
Leader 副本高水位
處理生產者請求的邏輯如下：
1、寫入消息到本地磁盤。
2、更新分區高水位值。
i. 獲取 Leader 副本所在 Broker 端保存的所有遠程副本 LEO 值（LEO-1，LEO-2，……，LEO-n）。
ii. 獲取 Leader 副本高水位值：currentHW。
iii. 更新 currentHW = max{currentHW, min（LEO-1, LEO-2, ……，LEO-n）}。
處理 Follower 副本拉取消息的邏輯如下：
1、讀取磁盤（或頁緩存）中的消息數據。
2、使用 Follower 副本發送請求中的位移值更新遠程副本 LEO 值。
3、更新分區高水位值（具體步驟與處理生產者請求的步驟相同）。
Follower 副本高水位
從 Leader 拉取消息的處理邏輯如下：
1、寫入消息到本地磁盤。
2、更新 LEO 值。
3、更新高水位值。
i. 獲取 Leader 發送的高水位值：currentHW。
ii. 獲取步驟 2 中更新過的 LEO 值：currentLEO。
iii. 更新高水位為 min(currentHW, currentLEO)。
高水位更新說明
新消息寫入時，先更新leader副本LEO，
follower副本新消息寫入后第一次拉消息，更新了follower副本的LEO，
follower第二次拉消息，leader副本更新remote LEO、HW；follower副本更新高水位
問題：Follower 端高水位的更新與 Leader 端有時間錯配。如果在這個短暫的滯后時間窗口內，接連發生 Broker 宕機，可能發生數據丟失。
背景：副本 A 和副本 B 都處於正常狀態，A 是 Leader 副本。某個使用了默認 acks 設置的生產者程序向 A 發送了兩條消息，A 全部寫入成功，此時 Kafka 會通知生產者說兩條消息全部發送成功。
1、副本 B 所在的 Broker 宕機，當它重啟回來后，副本 B 會執行日志截斷操作，將 LEO 值由2調整為之前的高水位值，也就是 1。
2、副本 B 開始從 A 拉取消息前，副本 A 所在的 Broker 宕機了，副本 B 成為新的 Leader，A 回來后，需要執行相同的日志截斷操作，即將高水位調整為與 B 相同的值，也就是 1。
影響：位移值為 1 的消息丟失。
Leader Epoch
它由兩部分數據組成。
- Epoch。一個單調增加的版本號。每當副本領導權發生變更時，都會增加該版本號。小版本號的 Leader 被認為是過期 Leader，不能再行使 Leader 權力。
- 起始位移（Start Offset）。Leader 副本在該 Epoch 值上寫入的首條消息的位移。
Kafka Broker 會在內存中為每個分區都緩存 Leader Epoch 數據，同時它還會定期地將這些信息持久化到一個 checkpoint 文件中。當 Leader 副本寫入消息到磁盤時，Broker 會嘗試更新這部分緩存。如果該 Leader 是首次寫入消息，那么 Broker 會向緩存中增加一個 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 會使用這個條目幫助判斷后續是否執行日志截斷操作。