Kafka HA Kafka一致性重要機制之ISR(kafka replica)

一、kafka replica

1. 當某個topic的replication-factor爲N且N大於1時，每個Partition都會有N個副本(Replica)。kafka的replica包含leader與follower。
2. Replica的個數小於等於Broker的個數，也就是說，對於每個Partition而言，每個Broker上最多隻會有一個Replica，因此可以使用Broker id 指定Partition的Replica。
3. 所有Partition的Replica默認情況會均勻分佈到所有Broker上。

二、Data Replication如何Propagate(擴散出去)消息？

每個Partition有一個leader與多個follower，producer往某個Partition中寫入數據是，只會往leader中寫入數據，然後數據纔會被複制進其他的Replica中。 
數據是由leader push過去還是有flower pull過來？ 
kafka是由follower週期性或者嘗試去pull(拉)過來(其實這個過程與consumer消費過程非常相似)，寫是都往leader上寫，但是讀並不是任意flower上讀都行，讀也只在leader上讀，flower只是數據的一個備份，保證leader被掛掉後頂上來，並不往外提供服務。

三、Data Replication何時Commit？

同步複製： 只有所有的follower把數據拿過去後才commit，一致性好，可用性不高。 
異步複製： 只要leader拿到數據立即commit，等follower慢慢去複製，可用性高，立即返回，一致性差一些。 
Commit：是指leader告訴客戶端，這條數據寫成功了。kafka儘量保證commit後立即leader掛掉，其他flower都有該條數據。

kafka不是完全同步，也不是完全異步，是一種ISR機制： 
1. leader會維護一個與其基本保持同步的Replica列表，該列表稱爲ISR(in-sync Replica)，每個Partition都會有一個ISR，而且是由leader動態維護 
2. 如果一個flower比一個leader落後太多，或者超過一定時間未發起數據複製請求，則leader將其重ISR中移除 
3. 當ISR中所有Replica都向Leader發送ACK時，leader才commit

既然所有Replica都向Leader發送ACK時，leader才commit，那麼flower怎麼會leader落後太多？ 
producer往kafka中發送數據，不僅可以一次發送一條數據，還可以發送message的數組；批量發送，同步的時候批量發送，異步的時候本身就是就是批量；底層會有隊列緩存起來，批量發送，對應broker而言，就會收到很多數據(假設1000)，這時候leader發現自己有1000條數據，flower只有500條數據，落後了500條數據，就把它從ISR中移除出去，這時候發現其他的flower與他的差距都很小，就等待；如果因爲內存等原因，差距很大，就把它從ISR中移除出去。

commit策略： 
server配置

  rerplica.lag.time.max.ms=10000
  # 如果leader發現flower超過10秒沒有向它發起fech請求，那麼leader考慮這個flower是不是程序出了點問題
  # 或者資源緊張調度不過來，它太慢了，不希望它拖慢後面的進度，就把它從ISR中移除。

  rerplica.lag.max.messages=4000 # 相差4000條就移除
  # flower慢的時候，保證高可用性，同時滿足這兩個條件後又加入ISR中，
  # 在可用性與一致性做了動態平衡   亮點

• 1
• 2
• 3
• 4
• 5
• 6
• 7

topic配置

  min.insync.replicas=1 # 需要保證ISR中至少有多少個replica

• 1

Producer配置

  request.required.asks=0
  # 0:相當於異步的，不需要leader給予回覆，producer立即返回，發送就是成功,
      那麼發送消息網絡超時或broker crash(1.Partition的Leader還沒有commit消息 2.Leader與Follower數據不同步)，
      既有可能丟失也可能會重發
  # 1：當leader接收到消息之後發送ack，丟會重發，丟的概率很小
  # -1：當所有的follower都同步消息成功後發送ack.  丟失消息可能性比較低

• 1
• 2
• 3
• 4
• 5
• 6

四、Data Replication如何處理Replica恢復

leader掛掉了，從它的follower中選舉一個作爲leader，並把掛掉的leader從ISR中移除，繼續處理數據。一段時間後該leader重新啓動了，它知道它之前的數據到哪裏了，嘗試獲取它掛掉後leader處理的數據，獲取完成後它就加入了ISR。

五、Data Replication如何處理Replica全部宕機

1、等待ISR中任一Replica恢復,並選它爲Leader

1. 等待時間較長,降低可用性
2. 或ISR中的所有Replica都無法恢復或者數據丟失,則該Partition將永不可用

2、選擇第一個恢復的Replica爲新的Leader,無論它是否在ISR中

1. 並未包含所有已被之前Leader Commit過的消息,因此會造成數據丟失
2. 可用性較高