點擊上方「藍字」關注我們
本系列主要講解kafka基本設計和原理分析，分如下內容：
基本概念
消息模型
kafka副本同步機制
kafka文件存儲機制
kafka數據可靠性和一致性保證
kafka leader選舉
kafka消息傳遞語義
Kafka集羣partitions/replicas默認分配解析
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。
上一節中的最小的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日誌。
往期推薦
點“在看”你懂得
