???????? 在日常開發(fā)過程中使用kafka來實限流削峰作用但是往往kafka會存放多份副本來防止數(shù)據(jù)丟失氯迂，那你知道他的機制是什么樣的嗎践叠？本篇文章就帶給大家講解下。
一嚼蚀、Kafka集群
???????? Kafka 使用 Zookeeper 來維護集群成員 (brokers) 的信息禁灼。每個 broker 都有一個唯一標識 broker.id，用于標識自己在集群中的身份轿曙，可以在配置文件 server.properties 中進行配置弄捕，或者由程序自動生成僻孝。下面是 Kafka brokers 集群自動創(chuàng)建的過程：
- 每一個 broker 啟動的時候，它會在 Zookeeper 的
/brokers/ids路徑下創(chuàng)建一個臨時節(jié)點守谓，并將自己的broker.id寫入穿铆，從而將自身注冊到集群； - 當有多個 broker 時斋荞，所有 broker 會競爭性地在 Zookeeper 上創(chuàng)建
/controller節(jié)點荞雏，由于 Zookeeper 上的節(jié)點不會重復(fù)，所以必然只會有一個 broker 創(chuàng)建成功平酿，此時該 broker 稱為 controller broker凤优。它除了具備其他 broker 的功能外，還負責(zé)管理主題分區(qū)及其副本的狀態(tài)蜈彼。 - 當 broker 出現(xiàn)宕機或者主動退出從而導(dǎo)致其持有的 Zookeeper 會話超時時筑辨，會觸發(fā)注冊在 Zookeeper 上的 watcher 事件，此時 Kafka 會進行相應(yīng)的容錯處理幸逆；如果宕機的是 controller broker 時棍辕，還會觸發(fā)新的 controller 選舉。
二还绘、副本機制
???????? 為了保證高可用楚昭，kafka 的分區(qū)是多副本的，如果一個副本丟失了蚕甥，那么還可以從其他副本中獲取分區(qū)數(shù)據(jù)哪替。但是這要求對應(yīng)副本的數(shù)據(jù)必須是完整的栋荸，這是 Kafka 數(shù)據(jù)一致性的基礎(chǔ)菇怀，所以才需要使用 controller broker 來進行專門的管理。下面將詳解介紹 Kafka 的副本機制晌块。
2.1 分區(qū)和副本
2.2 ISR機制
每個分區(qū)都有一個 ISR(in-sync Replica) 列表爱沟，用于維護所有同步的、可用的副本匆背。首領(lǐng)副本必然是同步副本呼伸，而對于跟隨者副本來說，它需要滿足以下條件才能被認為是同步副本：
- 與 Zookeeper 之間有一個活躍的會話钝尸，即必須定時向 Zookeeper 發(fā)送心跳括享；
- 在規(guī)定的時間內(nèi)從首領(lǐng)副本那里低延遲地獲取過消息。
如果副本不滿足上面條件的話珍促，就會被從 ISR 列表中移除铃辖，直到滿足條件才會被再次加入。
這里給出一個主題創(chuàng)建的示例：使用 --replication-factor 指定副本系數(shù)為 3猪叙，創(chuàng)建成功后使用 --describe 命令可以看到分區(qū) 0 的有 0,1,2 三個副本娇斩，且三個副本都在 ISR 列表中仁卷，其中 1 為首領(lǐng)副本。
2.3 不完全的首領(lǐng)選舉
對于副本機制犬第，在 broker 級別有一個可選的配置參數(shù) unclean.leader.election.enable锦积，默認值為 fasle，代表禁止不完全的首領(lǐng)選舉歉嗓。這是針對當首領(lǐng)副本掛掉且 ISR 中沒有其他可用副本時丰介，是否允許某個不完全同步的副本成為首領(lǐng)副本，這可能會導(dǎo)致數(shù)據(jù)丟失或者數(shù)據(jù)不一致遥椿，在某些對數(shù)據(jù)一致性要求較高的場景 (如金融領(lǐng)域)基矮，這可能無法容忍的，所以其默認值為 false冠场，如果你能夠允許部分數(shù)據(jù)不一致的話家浇，可以配置為 true。
2.4 最少同步副本
ISR 機制的另外一個相關(guān)參數(shù)是 min.insync.replicas , 可以在 broker 或者主題級別進行配置碴裙，代表 ISR 列表中至少要有幾個可用副本钢悲。這里假設(shè)設(shè)置為 2，那么當可用副本數(shù)量小于該值時舔株，就認為整個分區(qū)處于不可用狀態(tài)莺琳。此時客戶端再向分區(qū)寫入數(shù)據(jù)時候就會拋出異常 org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。
2.5 發(fā)送確認
Kafka 在生產(chǎn)者上有一個可選的參數(shù) ack载慈，該參數(shù)指定了必須要有多少個分區(qū)副本收到消息惭等，生產(chǎn)者才會認為消息寫入成功：
- acks=0 ：消息發(fā)送出去就認為已經(jīng)成功了，不會等待任何來自服務(wù)器的響應(yīng)办铡；
- acks=1 ：只要集群的首領(lǐng)節(jié)點收到消息辞做，生產(chǎn)者就會收到一個來自服務(wù)器成功響應(yīng)；
- acks=all ：只有當所有參與復(fù)制的節(jié)點全部收到消息時寡具，生產(chǎn)者才會收到一個來自服務(wù)器的成功響應(yīng)秤茅。
三、數(shù)據(jù)請求
3.1 元數(shù)據(jù)請求機制
???????? 在所有副本中童叠，只有領(lǐng)導(dǎo)副本才能進行消息的讀寫處理框喳。由于不同分區(qū)的領(lǐng)導(dǎo)副本可能在不同的 broker 上，如果某個 broker 收到了一個分區(qū)請求厦坛，但是該分區(qū)的領(lǐng)導(dǎo)副本并不在該 broker 上五垮，那么它就會向客戶端返回一個 Not a Leader for Partition 的錯誤響應(yīng)。為了解決這個問題杜秸，Kafka 提供了元數(shù)據(jù)請求機制放仗。
???????? 首先集群中的每個 broker 都會緩存所有主題的分區(qū)副本信息，客戶端會定期發(fā)送發(fā)送元數(shù)據(jù)請求亩歹，然后將獲取的元數(shù)據(jù)進行緩存匙监。定時刷新元數(shù)據(jù)的時間間隔可以通過為客戶端配置 metadata.max.age.ms 來進行指定凡橱。有了元數(shù)據(jù)信息后，客戶端就知道了領(lǐng)導(dǎo)副本所在的 broker亭姥，之后直接將讀寫請求發(fā)送給對應(yīng)的 broker 即可稼钩。
3.2 數(shù)據(jù)可見性
3.3 零拷貝
???????? Kafka 所有數(shù)據(jù)的寫入和讀取都是通過零拷貝來實現(xiàn)的。傳統(tǒng)拷貝與零拷貝的區(qū)別如下：
傳統(tǒng)模式下的四次拷貝與四次上下文切換
???????? 以將磁盤文件通過網(wǎng)絡(luò)發(fā)送為例达罗。傳統(tǒng)模式下坝撑，一般使用如下偽代碼所示的方法先將文件數(shù)據(jù)讀入內(nèi)存，然后通過 Socket 將內(nèi)存中的數(shù)據(jù)發(fā)送出去粮揉。
buffer?=?File.read
Socket.send(buffer)???????? 這一過程實際上發(fā)生了四次數(shù)據(jù)拷貝巡李。首先通過系統(tǒng)調(diào)用將文件數(shù)據(jù)讀入到內(nèi)核態(tài) Buffer（DMA 拷貝），然后應(yīng)用程序?qū)?nèi)存態(tài) Buffer 數(shù)據(jù)讀入到用戶態(tài) Buffer（CPU 拷貝）扶认，接著用戶程序通過 Socket 發(fā)送數(shù)據(jù)時將用戶態(tài) Buffer 數(shù)據(jù)拷貝到內(nèi)核態(tài) Buffer（CPU 拷貝）侨拦，最后通過 DMA 拷貝將數(shù)據(jù)拷貝到 NIC Buffer。同時辐宾，還伴隨著四次上下文切換狱从，如下圖所示：
sendfile和transferTo實現(xiàn)零拷貝
@Override
public?long?transferFrom(FileChannel?fileChannel,?long?position,?long?count)?throws?IOException?{
????return?fileChannel.transferTo(position,?count,?socketChannel);
}注： transferTo 和 transferFrom 并不保證一定能使用零拷貝。實際上是否能使用零拷貝與操作系統(tǒng)相關(guān)叠纹，如果操作系統(tǒng)提供 sendfile 這樣的零拷貝系統(tǒng)調(diào)用季研，則這兩個方法會通過這樣的系統(tǒng)調(diào)用充分利用零拷貝的優(yōu)勢，否則并不能通過這兩個方法本身實現(xiàn)零拷貝誉察。
四与涡、物理存儲
4.1 分區(qū)分配
在創(chuàng)建主題時，Kafka 會首先決定如何在 broker 間分配分區(qū)副本持偏，它遵循以下原則：
- 在所有 broker 上均勻地分配分區(qū)副本驼卖；
- 確保分區(qū)的每個副本分布在不同的 broker 上；
- 如果使用了
broker.rack參數(shù)為 broker 指定了機架信息综液，那么會盡可能的把每個分區(qū)的副本分配到不同機架的 broker 上款慨，以避免一個機架不可用而導(dǎo)致整個分區(qū)不可用儒飒。
基于以上原因谬莹，如果你在一個單節(jié)點上創(chuàng)建一個 3 副本的主題，通常會拋出下面的異常：
Error while executing topic command : org.apache.kafka.common.errors.InvalidReplicationFactor
Exception: Replication factor: 3 larger than available brokers: 1.4.2 分區(qū)數(shù)據(jù)保留規(guī)則
???????? 保留數(shù)據(jù)是 Kafka 的一個基本特性桩了， 但是 Kafka 不會一直保留數(shù)據(jù)附帽，也不會等到所有消費者都讀取了消息之后才刪除消息。相反井誉， Kafka 為每個主題配置了數(shù)據(jù)保留期限蕉扮，規(guī)定數(shù)據(jù)被刪除之前可以保留多長時間，或者清理數(shù)據(jù)之前可以保留的數(shù)據(jù)量大小颗圣。分別對應(yīng)以下四個參數(shù)：
-
log.retention.bytes：刪除數(shù)據(jù)前允許的最大數(shù)據(jù)量喳钟；默認值-1屁使，代表沒有限制； -
log.retention.ms：保存數(shù)據(jù)文件的毫秒數(shù)奔则，如果未設(shè)置蛮寂，則使用log.retention.minutes中的值，默認為 null易茬； -
log.retention.minutes：保留數(shù)據(jù)文件的分鐘數(shù)酬蹋，如果未設(shè)置，則使用log.retention.hours中的值抽莱，默認為 null范抓； -
log.retention.hours：保留數(shù)據(jù)文件的小時數(shù)，默認值為 168食铐，也就是一周匕垫。
???????? 因為在一個大文件里查找和刪除消息是很費時的，也很容易出錯虐呻，所以 Kafka 把分區(qū)分成若干個片段年缎，當前正在寫入數(shù)據(jù)的片段叫作活躍片段×蹇叮活動片段永遠不會被刪除单芜。如果按照默認值保留數(shù)據(jù)一周，而且每天使用一個新片段犁柜，那么你就會看到洲鸠，在每天使用一個新片段的同時會刪除一個最老的片段，所以大部分時間該分區(qū)會有 7 個片段存在馋缅。
4.3 文件格式
小結(jié)
???????? 本篇文章講解了關(guān)于kafka的存放副本的機制的原理扒腕，以及數(shù)據(jù)是如何存儲的kafka為了防止數(shù)據(jù)丟失添加了ack的方式，這個ack可能會影響一些效率萤悴，這ack的值可以根據(jù)場景進行設(shè)置比如說丟失一些數(shù)據(jù)沒有問題那就設(shè)置為0我將消息發(fā)出去我就不管了瘾腰。我在這里為大家提供大數(shù)據(jù)的資料需要的朋友可以去下面GitHub去下載胧奔，信自己唇礁，努力和汗水總會能得到回報的星掰。我是大數(shù)據(jù)老哥扔傅，我們下期見~~~
資源獲取 獲取Flink面試題案铺，Spark面試題批糟，程序員必備軟件赡艰，hive面試題瓢湃，Hadoop面試題伟众，Docker面試題析藕，簡歷模板等資源請去GitHub自行下載 https://github.com/lhh2002/Framework-Of-BigDataGitee 自行下載 ?https://gitee.com/li_hey_hey/dashboard/projects
