一骤坐、kafka replica
1绪杏、當(dāng)某個(gè)topic的replication-factor為N且N大于1時(shí)，每個(gè)Partition都會(huì)有N個(gè)副本(Replica)纽绍。kafka的replica包含leader與follower蕾久。
2、Replica的個(gè)數(shù)小于等于Broker的個(gè)數(shù)拌夏，也就是說(shuō)僧著，對(duì)于每個(gè)Partition而言，每個(gè)Broker上最多只會(huì)有一個(gè)Replica障簿，因此可以使用Broker id 指定Partition的Replica盹愚。
3、所有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. 丟失消息可能性比較低
注意：新版kafka中绵载，去除了rerplica.lag.max.messages設(shè)置埂陆，只保留了rerplica.lag.time.max.ms設(shè)置
四、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。
- 1)恩掷、等待時(shí)間較長(zhǎng)倡鲸，降低可用性。
- 2)黄娘、或ISR中的所有Replica都無(wú)法恢復(fù)或者數(shù)據(jù)丟失峭状，則該P(yáng)artition將永不可用克滴。
-
2、選擇第一個(gè)恢復(fù)的Replica為新的Leader,無(wú)論它是否在ISR中优床。
- 1)劝赔、并未包含所有已被之前Leader Commit過(guò)的消息，因此會(huì)造成數(shù)據(jù)丟失胆敞。
- 2)着帽、可用性較高。
參考：
https://blog.csdn.net/qq_37502106/article/details/80271800
