kafka知識體系-副本同步機制

本系列主要講解kafka基本設計和原理分析，分如下內容：

1. 基本概念
2. 消息模型
3. kafka副本同步機制
4. kafka文件存儲機制
5. kafka數據可靠性和一致性保證
6. kafka leader選舉
7. kafka消息傳遞語義
8. 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。

上一節中的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日志。

---

關於作者
愛編程、愛鑽研、愛分享、愛生活
關注分布式、高並發、數據挖掘
如需捐贈，請掃碼