kafka ISR設計及水印與leader epoch副本同步機制深刻剖析-kafka 商業環境實戰

版權聲明：本套技術專欄是做者（秦凱新）平時工做的總結和昇華，經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。版權聲明：禁止轉載，歡迎學習。QQ郵箱地址：1120746959@qq.com，若有任何商業交流，可隨時聯繫。

1 帽子理論（Gilbert 和 Lynch ）

• 一致性

  any read operation that begins after a write operation completes must 
    return that value, or the result of a later write operation
  
    經過某個節點的寫操做結果對後面經過其它節點的讀操做可見
    
    強一致性：
    若是更新數據後，併發訪問狀況下後續讀操做可當即感知該更新，稱爲強一致性。
    
    弱一致性：
    若是容許以後部分或者所有感知不到該更新，稱爲弱一致性。
    
    最終一致性：
    若在以後的一段時間（一般該時間不固定）後，必定能夠感知到該更新，稱爲最終一致性。
  複製代碼

• 可用性（Availability）

  every request received by a non-failing node in the system must result in a response
  
    任何一個沒有發生故障的節點必須在有限的時間內返回合理的結果。
  複製代碼

• 分區容忍性（Partition Tolerance）

  the network will be allowed to lose arbitrarily many messages sent from one node to another
  
    部分節點宕機或者沒法與其它節點通訊時，各分區間還可保持分佈式系統的功能。
  複製代碼

• 悖論總結：

  可用性限定在不管是否集羣節點宕機，只要有活着的節點，就會當即返回請求結果。若要限制返回結果必須是最近一次寫的結果，就比較悲劇，若容許分區容忍性 => 分佈式系統分區之間就存在數據同步機制，那麼就有可能由於分區心跳切斷，致使數據不一致。

2 partition本質就是爲了日誌備份（對外最小的存儲單元）

Kafka中topic的每一個partition有一個預寫式的日誌文件，雖然partition能夠繼續細分爲若干個segment文件，可是對於上層應用來講能夠將partition當作最小的存儲單元（一個有多個segment文件拼接的「巨型」文件），每一個partition都由一些列有序的、不可變的消息組成，這些消息被連續的追加到partition中。

• partition本質就是爲了日誌備份，利用多份日誌文件的副本（replica）備份來共同提供冗餘機制來保持系統的高可用性。
• kafka會把副本均勻的分配到全部的Broker上。在其中全部的副本中，會挑選一個Leader副原本對外提供服務，其餘的副本統稱爲follower副本，只能被動的向leader副本請求數據。

3 Partitioner 三分天下

下圖展現了3個Partition把一個Topic主題數據流分紅三份，經過Partioner路由依次追加到分區的末尾中。若是partition規則設置的合理，全部消息能夠均勻分佈到不一樣的partition裏，這樣就實現了水平擴展。

config/server.properties能夠設置num.partitions參數，實現主題數據分流。

3 Leader副本競選上崗（in-sync replicas）

• 每個分區都存在一個in-sync replicas。
• in-sync replicas集合中的每個副本都與leader保持同步狀態，不在裏面的保持不了同步狀態。
• 只有ISR中的副本纔有資格被選爲leader。
• Producer寫入的消息只有被ISR中的副本都接收到，才被視爲"已提交"。

4 水印HW與末端位移LEO => Leader副本

• 這裏着重強調一下，Leader副本水印HW才真正決定了對外可看到的消息數量。
• 全部的副本都有LEO和HW。
• Leader副本水印HW的更新發生在全部的副本都更新了最新的LEO後，Leader副本最終才認爲能夠更新Leader副本水印。

5 ISR設計優化（replica.lag.max.messages廢棄）

• 解決了producer忽然發起一大波消息，從而產生瞬時高峯流量。若設置replica.lag.max.messages=4，則follower副本會被瞬時的拉開距離，從而致使follower副本瞬間被踢出ISR。不過一段時間follower副本同步後，會再次進入ISR。
• 同步不一樣步，同步不一樣步反覆出現，是多大的性能浪費。
• 0.9.0.0開始採用 replica. lag. time. max. ms，默認是10s，可謂是明智之舉。

6 HW同步機制(Leader與follower的愛恨纏綿)

6.1 指哪打哪（HW指向哪裏？）

• 這裏重點強調，都是不管HW仍是LEO都是指向下一條消息
• 舉例以下：若是一個普通topic的某個分區副本的LEO是10，那麼該副本當前保存了10條消息，位移值範圍是[0, 9]。此時如有一個producer向該副本插入一條消息，則該條消息的位移值是10，而副本LEO值則更新成11。

6.2 Leader與follower的HW愛恨纏綿（兩階段請求定終身）

• follower 副本會不斷地向leader副本發送Fetch請求

（1）follower 副本對象什麼時候更新LEO？

follower 副本專屬線程不斷地向leader副本所在broker發送FETCH請求。

leader 副本發送 FETCH response 給follower副本。

Follower 拿到response以後取出位移數據寫入到本地底層日誌中，在該過程當中其LEO值會被更新。
複製代碼

（2）leader 端非本身副本對象什麼時候更新LEO？

leader 端非本身副本對象 LEO值是在leader端broker處理FETCH請求過程當中被更新的。
複製代碼

（3） follower 副本對象什麼時候更新HW？

Follower 副本對象更新HW是在其更新本地LEO以後。

一旦follower向本地日誌寫完數據後它就會嘗試更新其HW值。
算法爲取本地LEO與FETCH response中HW值的較小值
複製代碼

（4）leader 副本對象什麼時候更新HW？

Leader 副本對象處理 Follower FETCH請求時在更新完leader 端非本身副本對象的LEO後將嘗試更新其本身HW值

producer 端寫入消息會更新leader Replica的LEO

副本被踢出ISR時

某分區變動爲leader副本後
複製代碼

（5）兩階段請求定終身：

第一次fetch請求僅得到了當前的數據，fetchOffset < Leader LEO, 由於leader 端的非本身的副本leo 是根據fetch請求肯定的，所以，只有第二次請求時，fetchOffset纔會和Leader LEO相等，進而更新 leader HW ，進而響應爲 leader HW，進而更新 Folloer HW。

6.3 HW更新延遲帶來的刀山火海

• 由於 fetchOffset是實實在在的須要位移。因此只有第二輪請求時，Follower纔會在其現有位移的基礎上，加1進行請求，從而連鎖更新 會更新Leader非本身remoteLEO 和 Leader HW 和 Follower HW。
• 刀山火海就在一輪請求和第二輪請求之間發生了。

7 刀山火海敬請期待

本文實在麻煩，大牛的技術博客看起來總總有些詞不達意，我順便就直接口語化,但願帶來不一樣的效果。技術就是一層窗戶紙，看我把kafka和spark剖析的體無完膚。香港美景，一覽衆山小，技術道路上毅然前行！！

秦凱新 於深圳 201811230124