一、KAFKA 服務端日誌LEO和HW帶來的問題
KAFKA 服務端日誌LEO和HW無論是leader還是follow的HW更新都需要第二輪fetch才能完成，若在第二輪fetch中follow或leader崩潰則有可能帶來數據丟失或數據不一致問題。
1.1 數據丟失
該主題有兩個副本，其中A是leader，B是follow。設min.insync.replicas=1 and acks=-1則當生產者發送信息後只要leader A 寫入到底層，此時kafka就好通知生產者發送成功。
按照現有HW邏輯，fetch第一階段主要完成leader和follow LEO的更新第二階段纔是HW的更新。在第二階段首先是leader HW的更新，HW=min(leader leo,follow leo)=2，讀取數據後發送給follow B，B收到後正準備更新HW=min(leo=2.leader HW=2)=2但此時B所在broker崩潰。B重啓後，因爲HW沒有更新成功仍然是1故會將LEO截斷則LEO=1，offset=1的數據從日誌文件刪掉。B重啓後向A發fetch請求，此時A正好也宕機。則B成爲Leader。
當A重啓後，按照leader B的hw，A也會進行截斷，A上leo=hw=1。最終原來offset=1上的消息從這兩個副本都刪除，數據永遠丟失。
1.2 數據不一致
二 KAFKA 服務端日誌LEO和HW問題解決方案
產生兩個問題的原因是HW被作爲衡量副本備份成功的關鍵和崩潰重啓後截斷的標準，但HW更新是在fetch第二階段完成，中間充滿了不確定性。leader引入了leader epoch，用一對值（epoch，offset），epoch表示leader版本號，每次leader更換就自增一次，offset表示該epoch版本的leader寫入第一條消息的位移。每個leader broker都會保存，並定期寫入一個文件。當leader寫log底層文件時，會嘗試更新整個緩存：如這個leader第一次寫入則在緩存中增加一條；每個副本成爲leader時都會查詢這個緩存獲取對應版本的位移避免數據丟失和不一致。
