Kafka一致性重要機(jī)制是什么

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

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

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

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

三、Data Replication何時(shí)Commit？

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

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

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

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

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

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

commit策略：server配置

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

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

topic配置

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

Producer配置

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

四、Data Replication如何處理Replica恢復(fù)

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

五、Data Replication如何處理Replica全部宕機(jī)

1、等待ISR中任一Replica恢復(fù),并選它為L(zhǎng)eader

• 等待時(shí)間較長(zhǎng),降低可用性

• 或ISR中的所有Replica都無(wú)法恢復(fù)或者數(shù)據(jù)丟失,則該P(yáng)artition將永不可用

2、選擇第一個(gè)恢復(fù)的Replica為新的Leader,無(wú)論它是否在ISR中

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

• 可用性較高