Kafka副本同步機制

引用自：

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從同步副本列表移除。

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日誌會看起來像這樣

乙個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副本同步機制

kafka中topic的每個partition有乙個預寫式日誌檔案，每個partition都由一系列有序的 不可變的訊息組成，這些訊息被連續的追加到partition中，partition中的每個訊息都有乙個連續的序列號叫做offset，確定他在partition中的唯一位置。kafka每個topi...

Kafka ISR 副本同步機制

isr in sync replica 就是 kafka 為某個分割槽維護的一組同步集合，即每個分割槽都有自己的乙個 isr 集合，處於 isr 集合中的副本，意味著 follower 副本與 leader 副本保持同步狀態，只有處於 isr 集合中的副本才有資格被選舉為 leader。一條 kaf...

kafka 副本機制

kafka通過副本機制保證資料的可靠性 一.副本機制的概念如下 1.乙個partition有多個副本replication,一般是3個或5個 2.每個副本位於不通的broker 3.每個副本集合裡有乙個leader副本,其餘的為follower副本,只有leader副本才接受讀寫請求,followe...