kafka副本同步機制

　　kafka副本同步機制

　　Kafka中主題的每一個Partition有一個預寫式日誌文件，每一個Partition都由一系列有序的、不可變的消息組成，這些消息被連續的追加到Partition中，Partition中的每一個消息都有一個連續的序列號叫作offset， 肯定它在分區日誌中惟一的位置。

　　

　　Kafka每一個topic的partition有N個副本，其中N是topic的複製因子。Kafka經過多副本機制實現故障自動轉移，當Kafka集羣中一個Broker失效狀況下仍然保證服務可用。在Kafka中發生複製時確保partition的預寫式日誌有序地寫到其餘節點上。N個replicas中。其中一個replica爲leader，其餘都爲follower，leader處理partition的全部讀寫請求，與此同時，follower會被動按期地去複製leader上的數據。

　　以下圖所示，Kafka集羣中有4個broker, 某topic有3個partition,且複製因子即副本個數也爲3：

　　

　　Kafka提供了數據複製算法保證，若是leader發生故障或掛掉，一個新leader被選舉並被接受客戶端的消息成功寫入。Kafka確保從同步副本列表中選舉一個副本爲leader，或者說follower追趕leader數據。leader負責維護和跟蹤ISR(In-Sync Replicas的縮寫，表示副本同步隊列，具體可參考下節)中全部follower滯後的狀態。當producer發送一條消息到broker後，leader寫入消息並複製到全部follower。消息提交以後才被成功複製到全部的同步副本。消息複製延遲受最慢的follower限制，重要的是快速檢測慢副本，若是follower「落後」太多或者失效，leader將會把它從ISR中刪除。

　　副本同步隊列(ISR)

　　所謂同步，必須知足以下兩個條件：

　　副本節點必須能與zookeeper保持會話(心跳機制)

　　副本能複製leader上的全部寫操做，而且不能落後太多。(卡住或滯後的副本控制是由 replica.lag.time.max.ms 配置)

　　默認狀況下Kafka對應的topic的replica數量爲1，即每一個partition都有一個惟一的leader，爲了確保消息的可靠性，一般應用中將其值(由broker的參數offsets.topic.replication.factor指定)大小設置爲大於1，好比3。 全部的副本(replicas)統稱爲Assigned Replicas，即AR。ISR是AR中的一個子集，由leader維護ISR列表，follower從leader同步數據有一些延遲。任意一個超過閾值都會把follower剔除出ISR, 存入OSR(Outof-Sync Replicas)列表，新加入的follower也會先存放在OSR中。AR=ISR+OSR。

　　上一節中的HW俗稱高水位，是HighWatermark的縮寫，取一個partition對應的ISR中最小的LEO做爲HW，consumer最多隻能消費到HW所在的位置。另外每一個replica都有HW,leader和follower各自負責更新本身的HW的狀態。對於leader新寫入的消息，consumer不能馬上消費，leader會等待該消息被全部ISR中的replicas同步後更新HW，此時消息才能被consumer消費。這樣就保證了若是leader所在的broker失效，該消息仍然能夠重新選舉的leader中獲取。對於來自內部broKer的讀取請求，沒有HW的限制。

　　下圖詳細的說明了當producer生產消息至broker後，ISR以及HW和LEO的流轉過程：

　　

　　因而可知，Kafka的複製機制既不是徹底的同步複製，也不是單純的異步複製。事實上，同步複製要求全部能工做的follower都複製完，這條消息纔會被commit，這種複製方式極大的影響了吞吐率。而異步複製方式下，follower異步的從leader複製數據，數據只要被leader寫入log就被認爲已經commit，這種狀況下若是follower都尚未複製完，落後於leader時，忽然leader宕機，則會丟失數據。而Kafka的這種使用ISR的方式則很好的均衡了確保數據不丟失以及吞吐率。

　　Kafka的ISR的管理最終都會反饋到Zookeeper節點上。具體位置爲：/brokers/topics/[topic]/partitions/[partition]/state。目前有兩個地方會對這個Zookeeper的節點進行維護：

　　Controller來維護：Kafka集羣中的其中一個Broker會被選舉爲Controller，主要負責Partition管理和副本狀態管理，也會執行相似於重分配partition之類的管理任務。在符合某些特定條件下，Controller下的LeaderSelector會選舉新的leader，ISR和新的leader_epoch及controller_epoch寫入Zookeeper的相關節點中。同時發起LeaderAndIsrRequest通知全部的replicas。

　　leader來維護：leader有單獨的線程按期檢測ISR中follower是否脫離ISR, 若是發現ISR變化，則會將新的ISR的信息返回到Zookeeper的相關節點中。

　　副本不一樣步的異常狀況

　　慢副本：在必定週期時間內follower不能追遇上leader。最多見的緣由之一是I / O瓶頸致使follower追加複製消息速度慢於從leader拉取速度。

　　卡住副本：在必定週期時間內follower中止從leader拉取請求。follower replica卡住了是因爲GC暫停或follower失效或死亡。

　　新啓動副本：當用戶給主題增長副本因子時，新的follower不在同步副本列表中，直到他們徹底遇上了leader日誌。

​