引用自：http://blog.csdn.net/lizhitao/article/details/51718185

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必須提供數據復制算法，保證如果leader發生故障或掛掉，一個新leader被選舉並接收客戶端的消息成功寫入。Kafka確保從同步副本列表中選舉一個副本為leader,或者換句話說,follower追趕leader數據。leader負責維護和跟蹤同步副本列表中所有follower滯後狀態。當生產者發送一條消息到Broker,leader寫入消息並復制到所有follower。消息提交之後才被成功復制到所有的同步副本。消息復制延遲受最慢的follower限制,重要的是快速檢測慢副本,如果follower”落後”太多或者失效,leader將會把它從replicas從同步副本列表移除。

partition的follower追上leader含義

Kafka中每個partition的follower沒有“趕上”leader的日誌可能會從同步副本列表中移除。下面用一個例子解釋一下“追趕”到底是什麽意思。請看一個例子：主題名稱為foo 1 partition 3 replicas。假如partition的replication分布在Brokers 1、2和3上，並且Broker 3消息已經成功提交。同步副本列表中1為leader、2和3為follower。假設replica.lag.max.messages設置為4，表明只要follower落後leader不超過3，就不會從同步副本列表中移除。replica.lag.time.max設置為500 ms，表明只要follower向leader發送請求時間間隔不超過500 ms，就不會被標記為死亡,也不會從同步副本列中移除。

下面看看，生產者發送下一條消息寫入leader，與此同時follower Broker 3 GC暫停，如下圖所示:

直到follower Broker 3從同步副本列表中移除或追趕上leader log end offset，最新的消息才會認為提交。註意,因為follower Broker 3小於replica.lag.max.messages= 4落後於leader Broker 1，Kafka不會從同步副本列表中移除。在這種情況下,這意味著follower Broker 3需要迎頭追趕上知道offset = 6,如果是,那麽它完全“趕上” leader Broker 1 log end offset。讓我們假設代理3出來的GC暫停在100 ms和追趕上領袖的日誌結束偏移量。在這種狀態下，下面partition日誌會看起來像這樣

一個副本可以不同步Leader有如下幾個原因

• 慢副本：在一定周期時間內follower不能追趕上leader。最常見的原因之一是I / O瓶頸導致follower追加復制消息速度慢於從leader拉取速度
• 卡住副本：在一定周期時間內follower停止從leader拉取請求。follower replica卡住了是由於GC暫停或follower失效或死亡。
• 新啟動副本：當用戶給主題增加副本因子時，新的follower不在同步副本列表中，直到他們完全趕上了leader日誌。

一個partition的follower落後於leader足夠多時，被認為不在同步副本列表或處於滯後狀態。在Kafka-0.8.2.x中,副本滯後判斷依據是副本落後於leader最大消息數量(replica.lag.max.messages)或replicas響應partition leader的最長等待時間(replica.lag.time.max.ms)。前者是用來檢測緩慢的副本,而後者是用來檢測失效或死亡的副本

如何確定副本是滯後的？

這個模型檢測不同步卡住副本列表工作下所有情況都適用。它追蹤follower replica時間內沒有向leader發送拉取請求,表明它已經死了。另一方面,如果均勻流量模式情況下，為一個主題或多個主題設置這些參數檢測模型不同步慢副本列表消息的數量會工作很好,但我們發現生產環境中它不擴展到所有主題各種工作負載。

接著上面的例子,如果主題foo獲取數據速率2 msg/sec，leader單次批量接收一般不會超過3條消息,然後你知道主題參數replica.lag.max.messages設置為4。為什麽?因為follower replica從leader復制消息前，已經有大批量消息寫leader，follower replica落後於leader不超過3條消息 。另一方面，如果主題foo的follower replica初始落後於leader持續超過3消息,leader會從同步副本列表中移除慢副本，避免消息寫延遲增加。

這本質上是replica.lag.max.messages的目標。能夠檢測follower與leader不一致且從同步副本列表移除。然而,主題在流量高峰期發送了一批消息(4條消息),等於replica.lag.max.messages = 4配置值。在那一瞬間,2個follower replica將被認為是”out-of-sync”並且leader會從同步副本列表中移除。

2個follower replica都是活著,下次拉取請求他們會趕上leader log end offset並重新加入同步副本列表。重復相同的過程，如果生產者繼續發送相對一批較大消息到leader。這種情況演示了當follower replica頻繁在從同步副本列表移除和重新加入同步副本列表之間來回切換時，不必要觸發虛假警報。

副本配置規則

我們認為真正重要的事情是檢測卡或慢副本,這段時間follower replica是“out-of-sync”落後於leader。在服務端現在只有一個參數需要配置replica.lag.time.max.ms。這個參數解釋replicas響應partition leader的最長等待時間。檢測卡住或失敗副本的探測——如果一個replica失敗導致發送拉取請求時間間隔超過replica.lag.time.max.ms。Kafka會認為此replica已經死亡會從同步副本列表從移除。檢測慢副本機制發生了變化——如果一個replica開始落後leader超過replica.lag.time.max.ms。Kafka會認為太緩慢並且會從同步副本列表中移除。除非replica請求leader時間間隔大於replica.lag.time.max.ms，因此即使leader使流量激增和大批量寫消息。Kafka也不會從同步副本列表從移除該副本。

Kafka副本同步機制