掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
作者:聞數(shù)起舞 2020-06-28 07:39:44
開發(fā)
架構(gòu)
Kafka 現(xiàn)在,每個公司都在互聯(lián)網(wǎng)系統(tǒng)中使用Kafka。 Kafka似乎是解決分布式并提高系統(tǒng)吞吐量的最佳松耦合解決方案之一。

讓客戶滿意是我們工作的目標(biāo),不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶,將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴,公司提供的服務(wù)項目有:域名申請、網(wǎng)站空間、營銷軟件、網(wǎng)站建設(shè)、武陵源網(wǎng)站維護、網(wǎng)站推廣。
現(xiàn)在,每個公司都在互聯(lián)網(wǎng)系統(tǒng)中使用Kafka。 Kafka似乎是解決分布式并提高系統(tǒng)吞吐量的最佳松耦合解決方案之一。
我大約6年前開始使用Kafka。 當(dāng)時,我在Aerohive工作。 為了解決企業(yè)wifi設(shè)備帶來的大量日志,傳統(tǒng)的消息傳遞系統(tǒng)RabbitMQ和ActiveMQ已經(jīng)不堪重負(fù)。
此時,Kafka誕生了(2012年),并提供了一個完美的解決方案。
重要要點:
什么是消息系統(tǒng)?
在了解Kafka之前,如果您不知道什么是Message Queue,則需要添加它。 如果您已經(jīng)知道,則可以跳到下一段。
> Morden Distributed System
如上圖所述,Message Queue是一個在兩個系統(tǒng)之間傳輸和存儲消息的中間件。 其外觀具有以下優(yōu)點:
同時,我認(rèn)為最大的缺點是復(fù)雜性,其優(yōu)點完全可以忽略不計。
Kafka如何運作?
對于Kafka而言,從獨立的角度來看,其中包括生產(chǎn)者,消費者和經(jīng)紀(jì)人。
> Kafka components
如圖所示,不同的生產(chǎn)者可以將消息發(fā)送到多個主題的多個分區(qū),而消費者也可以從各種主題中消費。
生產(chǎn)者和消費者完全孤立。
在此設(shè)計中,它充分體現(xiàn)了去耦,靈活性和峰值處理能力,訂單保證和異步通信。
Kafka如何在分布式環(huán)境中工作?
1. 集群
多個代理和副本。
Kafka如何保證冗余,可恢復(fù)性和高可用性?
即使某些節(jié)點發(fā)生故障,復(fù)制也可以提供高可用性:
基于仲裁的復(fù)制可以使用筏和Paxos等算法,例如Zookeeper,Google Spanner等。在2n +1個節(jié)點的情況下,最多可以容忍n個節(jié)點故障。
僅在成功接收到消息后,基于主數(shù)據(jù)庫的復(fù)制以及其他主數(shù)據(jù)庫和備份的寫入操作才能成功。 對于n個節(jié)點,最多可以容忍n-1個節(jié)點故障,例如Microsoft的PacifiaA。
這兩種方法各有優(yōu)缺點。
Kafka采用第二種方法,即主從模式,該方法主要基于容錯能力,并且在兩個節(jié)點的情況下也可以提供高可用性。
如果節(jié)點很慢怎么辦?
首先,這種情況很少發(fā)生。 如果發(fā)生這種情況,您可以設(shè)置超時參數(shù)來處理這種情況。
Kafka的復(fù)制適用于分區(qū)。
例如,在上圖中,有四個代理,一個主題和兩個分區(qū)。 復(fù)制因子是三。 當(dāng)生產(chǎn)者發(fā)送消息時,它將選擇一個分區(qū),例如topic1-part1分區(qū),將消息發(fā)送到該分區(qū)的領(lǐng)導(dǎo)者,broker2,broker3將拉出消息,消息被拉出后,從屬將發(fā)送ack到 主機,這次主機僅提交此日志。
在此過程中,生產(chǎn)者有兩種選擇:
在第一個中,您可以確保在異常情況下不會丟失消息,但是延遲會減少。 后者的等待時間已大大改善,但是一旦出現(xiàn)異常情況,從屬服務(wù)器將無法在領(lǐng)導(dǎo)掛起之前提取最新消息。 在這種情況下,可能會丟失該消息。
2. 客戶群
消費者使用消費者組名稱標(biāo)記自己,并且發(fā)布到主題的每條記錄都會傳遞到每個訂閱消費者組中的一個消費者實例。 使用者實例可以在單獨的進程中或在單獨的機器上。
如果所有使用者實例都具有相同的使用者組,那么將在這些使用者實例上有效地平衡記錄。
如果所有使用者實例具有不同的使用者組,則每條記錄將廣播到所有使用者進程形成正式文件
簡而言之,消費者群體是Kafka生態(tài)系統(tǒng)中的真正消費者。
3. 控制者
上圖是2015年Kafka Controller的設(shè)計圖。 Controller和ZK共同構(gòu)建了Kafka的高層架構(gòu),該架構(gòu)主要完成以下任務(wù):
為什么Kafka這么快?
Kafka中有一個過程,其中大量網(wǎng)絡(luò)數(shù)據(jù)被持久保存到磁盤(生產(chǎn)者到代理),并且磁盤文件通過網(wǎng)絡(luò)發(fā)送(經(jīng)紀(jì)人到消費者)。
此過程的性能直接影響Kafka的整體吞吐量。
1. 零復(fù)制
上圖的左側(cè)是傳統(tǒng)的四個副本和四個上下文切換。
在上圖的右側(cè),Kafka使用Linux 2.4+內(nèi)核sendfile系統(tǒng)調(diào)用來實現(xiàn)零復(fù)制。
因為sendfile調(diào)用完成了整個文件讀取網(wǎng)絡(luò)的傳輸,所以整個過程只有兩個上下文切換,因此性能大大提高了。
準(zhǔn)確地說,Kafka的數(shù)據(jù)傳輸是通過TransportLayer完成的,其子類PlaintextTransportLayer通過Java NIO的FileChannel的transferTo和transferFrom方法實現(xiàn)了零復(fù)制。
2. 順序訪問
> Compare
上圖顯示,即使順序讀取磁盤,順序訪問的巨大優(yōu)勢也比基于內(nèi)存的隨機訪問要好。
Kafka中的每條消息都會被追加,并且不會從中間寫入或刪除消息,以確保順序訪問磁盤。
即使是順序讀取和寫入,過多的小型IO操作也會導(dǎo)致磁盤瓶頸,并且這次變成了隨機讀取和寫入。
Kafka的策略是匯總消息并分批發(fā)送,以最大程度地減少對磁盤的訪問。 因此,Kafka的主題和分區(qū)的數(shù)量不應(yīng)過多。
通常,經(jīng)過64個主題/分區(qū)之后,Kafka的性能將急劇下降。
3. 段日志
這種分區(qū)分割和索引設(shè)計不僅提高了數(shù)據(jù)讀取的效率,而且還提高了數(shù)據(jù)操作的并行性。
4. 高性能Broker
Kafka在Broker中的設(shè)計也是其如此之快的原因之一。
首先,客戶端發(fā)送的所有請求都將發(fā)送到接受器。 代理中將默認(rèn)有三個線程。 這三個線程稱為處理器。
接受者將不會對客戶的請求進行任何處理,而是直接對其進行封裝。 將socketChannel發(fā)送到這些處理器以形成隊列。
發(fā)送的方法是輪詢,即先發(fā)送到第一個處理器,然后再發(fā)送到第二個,第三個處理器,然后再返回到第一個處理器。 當(dāng)使用者線程使用這些socketChannel時,它將獲取請求請求,并且數(shù)據(jù)將伴隨這些請求請求。
默認(rèn)情況下,線程池中有八個線程。 這些線程用于處理請求和解析請求。 如果請求是書面請求,則將其寫入磁盤。 如果讀取,則返回結(jié)果。 處理器將從響應(yīng)中讀取響應(yīng)數(shù)據(jù),然后將其返回給客戶端。
這是Kafka的三層網(wǎng)絡(luò)架構(gòu)。
因此,如果我們需要增強和調(diào)整Kafka,增加處理器并增加線程池中的處理線程,則可以達到效果。 考慮到處理器生成請求的速度過快,并且線程數(shù)量不足以及時處理請求,因此請求和響應(yīng)實際上是一種緩存效果。
總結(jié)
我希望本文對您了解和初步了解Kafka,它具有的組件以及為什么可以實現(xiàn)如此高的性能有所幫助。
Kafka在現(xiàn)代高并發(fā)系統(tǒng)體系結(jié)構(gòu)中扮演著至關(guān)重要的角色,并且仍在快速發(fā)展,例如流媒體。
本文僅從概念和簡單設(shè)計原理方面說明Kafka。 僅僅掌握它是不夠的。
如果您需要更深入的分析,請參閱官方文檔。
謝謝閱讀!

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流