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

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

每個Partition有一個leader與多個follower，producer往某個Partition中寫入數(shù)據(jù)是，只會往leader中寫入數(shù)據(jù)，然后數(shù)據(jù)才會被復制進其他的Replica中。數(shù)據(jù)是由leader push過去還是有flower pull過來？

kafka是由follower周期性或者嘗試去pull(拉)過來(其實這個過程與consumer消費過程非常相似)，寫是都往leader上寫，但是讀并不是任意flower上讀都行，讀也只在leader上讀，flower只是數(shù)據(jù)的一個備份，保證leader被掛掉后頂上來，并不往外提供服務。

三、Data Replication何時Commit？

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

kafka不是完全同步，也不是完全異步，是一種ISR機制：

1. leader會維護一個與其基本保持同步的Replica列表，該列表稱為ISR(in-sync Replica)，每個Partition都會有一個ISR，而且是由leader動態(tài)維護

2. 如果一個flower比一個leader落后太多，或者超過一定時間未發(fā)起數(shù)據(jù)復制請求，則leader將其重ISR中移除

3. 當ISR中所有Replica都向Leader發(fā)送ACK時，leader才commit

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

commit策略：server配置

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

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

topic配置

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

Producer配置

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

四、Data Replication如何處理Replica恢復

leader掛掉了，從它的follower中選舉一個作為leader，并把掛掉的leader從ISR中移除，繼續(xù)處理數(shù)據(jù)。一段時間后該leader重新啟動了，它知道它之前的數(shù)據(jù)到哪里了，嘗試獲取它掛掉后leader處理的數(shù)據(jù)，獲取完成后它就加入了ISR。

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

1、等待ISR中任一Replica恢復,并選它為Leader

• 等待時間較長,降低可用性

• 或ISR中的所有Replica都無法恢復或者數(shù)據(jù)丟失,則該Partition將永不可用

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

• 并未包含所有已被之前Leader Commit過的消息,因此會造成數(shù)據(jù)丟失

• 可用性較高