當(dāng)前位置:首頁(yè) > 公眾號(hào)精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]1kafka簡(jiǎn)介??Kafka是一個(gè)分布式的基于發(fā)布/訂閱模式的消息隊(duì)列(MessageQueue),主要應(yīng)用與大數(shù)據(jù)實(shí)時(shí)處理領(lǐng)域。其主要設(shè)計(jì)目標(biāo)如下:?以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力,即使對(duì)TB級(jí)以上數(shù)據(jù)也能保證常數(shù)時(shí)間的訪問(wèn)性能?高吞吐率。即使在非常廉價(jià)的機(jī)器...




1kafka簡(jiǎn)介


Kafka 是一個(gè)分布式的基于發(fā)布/訂閱模式的消息隊(duì)列(Message Queue),主要應(yīng)用與大數(shù)據(jù)實(shí)時(shí)處理領(lǐng)域。其主要設(shè)計(jì)目標(biāo)如下:


  1. 以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力,即使對(duì)TB級(jí)以上數(shù)據(jù)也能保證常數(shù)時(shí)間的訪問(wèn)性能


  2. 高吞吐率。即使在非常廉價(jià)的機(jī)器上也能做到單機(jī)支持每秒100K條消息的傳輸


  3. 支持Kafka Server間的消息分區(qū),及分布式消費(fèi),同時(shí)保證每個(gè)partition內(nèi)的消息順序傳輸,同時(shí)支持離線數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理



2為什么要用消息系統(tǒng)


Kafka 本質(zhì)上是一個(gè) MQ(Message Queue),使用消息隊(duì)列的好處?
  1. 解耦:允許我們獨(dú)立修改隊(duì)列兩邊的處理過(guò)程而互不影響。


  2. 冗余:有些情況下,我們?cè)谔幚頂?shù)據(jù)的過(guò)程會(huì)失敗造成數(shù)據(jù)丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理,通過(guò)這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn), 確保你的數(shù)據(jù)被安全的保存直到你使用完畢


  3. 峰值處理能力:不會(huì)因?yàn)橥话l(fā)的流量請(qǐng)求導(dǎo)致系統(tǒng)崩潰,消息隊(duì)列能夠使服務(wù)頂住突發(fā)的訪問(wèn)壓力, 有助于解決生產(chǎn)消息和消費(fèi)消息的處理速度不一致的情況


  4. 異步通信:消息隊(duì)列允許用戶把消息放入隊(duì)列但不立即處理它, 等待后續(xù)進(jìn)行消費(fèi)處理。




3kafka基礎(chǔ)知識(shí)


下面給出 Kafka 一些重要概念,讓大家對(duì) Kafka 有個(gè)整體的認(rèn)識(shí)和感知


  1. Producer:即消息生產(chǎn)者,向 Kafka Broker 發(fā)消息的客戶端。


  2. Consumer:消息消費(fèi)者,從 Kafka Broker 讀消息的客戶端。


  3. Consumer Group:消費(fèi)者組,消費(fèi)者組內(nèi)每個(gè)消費(fèi)者負(fù)責(zé)消費(fèi)不同分區(qū)的數(shù)據(jù),以提高消費(fèi)能力。一個(gè)分區(qū)只能由組內(nèi)一個(gè)消費(fèi)者消費(fèi),不同消費(fèi)者組之間互不影響。


  4. Broker:一臺(tái) Kafka 機(jī)器就是一個(gè) Broker。一個(gè)集群是由多個(gè) Broker 組成的且一個(gè) Broker 可以容納多個(gè) Topic。


  5. Topic:可以簡(jiǎn)單理解為隊(duì)列,Topic 將消息分類,生產(chǎn)者和消費(fèi)者面向的都是同一個(gè) Topic。


  6. Partition:為了實(shí)現(xiàn)Topic擴(kuò)展性,提高并發(fā)能力,一個(gè)非常大的 Topic 可以分布到多個(gè) Broker 上,一個(gè) Topic 可以分為多個(gè) Partition 進(jìn)行存儲(chǔ),每個(gè) Partition 是一個(gè)有序的隊(duì)列。


  7. Replica:副本,為實(shí)現(xiàn)數(shù)據(jù)備份的功能,保證集群中的某個(gè)節(jié)點(diǎn)發(fā)生故障時(shí),該節(jié)點(diǎn)上的 Partition 數(shù)據(jù)不丟失,且 Kafka 仍然能夠繼續(xù)工作,為此Kafka提供了副本機(jī)制,一個(gè) Topic 的每個(gè) Partition 都有若干個(gè)副本,一個(gè) Leader 副本和若干個(gè) Follower 副本。


  8. Leader:即每個(gè)分區(qū)多個(gè)副本的主副本,生產(chǎn)者發(fā)送數(shù)據(jù)的對(duì)象,以及消費(fèi)者消費(fèi)數(shù)據(jù)的對(duì)象,都是 Leader。


  9. Follower:即每個(gè)分區(qū)多個(gè)副本的從副本,會(huì)實(shí)時(shí)從 Leader 副本中同步數(shù)據(jù),并保持和 Leader 數(shù)據(jù)的同步。Leader 發(fā)生故障時(shí),某個(gè) Follower 還會(huì)被選舉并成為新的 Leader , 且不能跟 Leader 在同一個(gè)broker上, 防止崩潰數(shù)據(jù)可恢復(fù)。


  10. Offset:消費(fèi)者消費(fèi)的位置信息,監(jiān)控?cái)?shù)據(jù)消費(fèi)到什么位置,當(dāng)消費(fèi)者掛掉再重新恢復(fù)的時(shí)候,可以從消費(fèi)位置繼續(xù)消費(fèi)。


  11. ZooKeeper服務(wù):Kafka 集群能夠正常工作,需要依賴于 ZooKeeper,ZooKeeper 幫助 Kafka 存儲(chǔ)和管理集群元數(shù)據(jù)信息。在最新版本中, 已經(jīng)慢慢要脫離 ZooKeeper






4kafka集群架構(gòu)


工作流程


在了解kafka集群之前, 我們先來(lái)了解下kafka的工作流程, Kafka集群會(huì)將消息流存儲(chǔ)在 Topic 的中,每條記錄會(huì)由一個(gè)Key、一個(gè)Value和一個(gè)時(shí)間戳組成。





Kafka 中消息是以 Topic 進(jìn)行分類的,生產(chǎn)者生產(chǎn)消息,消費(fèi)者消費(fèi)消息,讀取和消費(fèi)的都是同一個(gè) Topic。但是Topic 是邏輯上的概念, Partition 是物理上的概念,每個(gè) Partition 對(duì)應(yīng)一個(gè) log 文件,該 log 文件中存儲(chǔ)的就是 Producer 生產(chǎn)的數(shù)據(jù)。Producer 端生產(chǎn)的數(shù)據(jù)會(huì)不斷順序追加到該 log 文件末尾,并且每條數(shù)據(jù)都會(huì)記錄有自己的 Offset。而消費(fèi)者組中的每個(gè)消費(fèi)者,也都會(huì)實(shí)時(shí)記錄當(dāng)前自己消費(fèi)到了哪個(gè) Offset,方便在崩潰恢復(fù)時(shí),可以繼續(xù)從上次的 Offset 位置消費(fèi)。


存儲(chǔ)機(jī)制



此時(shí) Producer 端生產(chǎn)的消息會(huì)不斷追加到 log 文件末尾,這樣文件就會(huì)越來(lái)越大, 為了防止 log 文件過(guò)大導(dǎo)致數(shù)據(jù)定位效率低下,那么Kafka 采取了分片和索引機(jī)制。它將每個(gè) Partition 分為多個(gè) Segment,每個(gè) Segment 對(duì)應(yīng)4個(gè)文件:“.index” 索引文件, “.log” 數(shù)據(jù)文件, “.snapshot” 快照文件, “.timeindex” 時(shí)間索引文件。這些文件都位于同一文件夾下面,該文件夾的命名規(guī)則為:topic 名稱-分區(qū)號(hào)。例如, heartbeat心跳上報(bào)服務(wù) 這個(gè) topic 有三個(gè)分區(qū),則其對(duì)應(yīng)的文件夾為 heartbeat-0,heartbeat-1,heartbeat-2這樣。


index, log, snapshot, timeindex 文件以當(dāng)前 Segment 的第一條消息的 Offset 命名。其中 “.index” 文件存儲(chǔ)大量的索引信息,“.log” 文件存儲(chǔ)大量的數(shù)據(jù),索引文件中的元數(shù)據(jù)指向?qū)?yīng)數(shù)據(jù)文件中 Message 的物理偏移量。


下圖為index 文件和 log 文件的結(jié)構(gòu)示意圖:






Replica - 副本


kafka中的 Partition 為了保證數(shù)據(jù)安全,每個(gè) Partition 可以設(shè)置多個(gè)副本。此時(shí)我們對(duì)分區(qū)0,1,2分別設(shè)置3個(gè)副本(注:設(shè)置兩個(gè)副本是比較合適的)。而且每個(gè)副本都是有"角色"之分的,它們會(huì)選取一個(gè)副本作為 Leader 副本,而其他的作為 Follower 副本,我們的 Producer 端在發(fā)送數(shù)據(jù)的時(shí)候,只能發(fā)送到Leader Partition里面 ,然后Follower Partition會(huì)去Leader那自行同步數(shù)據(jù), Consumer 消費(fèi)數(shù)據(jù)的時(shí)候,也只能從 Leader 副本那去消費(fèi)數(shù)據(jù)的。




Controller


Kafka Controller,其實(shí)就是一個(gè) Kafka 集群中一臺(tái) Broker,它除了具有普通Broker 的消息發(fā)送、消費(fèi)、同步功能之外,還需承擔(dān)一些額外的工作。Kafka 使用公平競(jìng)選的方式來(lái)確定 Controller ,最先在 ZooKeeper 成功創(chuàng)建臨時(shí)節(jié)點(diǎn) /controller 的Broker會(huì)成為 Controller ,一般而言,Kafka集群中第一臺(tái)啟動(dòng)的 Broker 會(huì)成為Controller,并將自身 Broker 編號(hào)等信息寫入ZooKeeper臨時(shí)節(jié)點(diǎn)/controller。




Offset 的維護(hù)


Consumer 在消費(fèi)過(guò)程中可能會(huì)出現(xiàn)斷電宕機(jī)等故障,在 Consumer 恢復(fù)后,需要從故障前的 Offset 位置繼續(xù)消費(fèi)。所以 Consumer 需要實(shí)時(shí)記錄自己消費(fèi)到了哪個(gè) Offset,以便故障恢復(fù)后繼續(xù)消費(fèi)。在 Kafka 0.9 版本之前,Consumer 默認(rèn)將 Offset 保存在 ZooKeeper 中,但是從 0.9 版本開(kāi)始,Consumer 默認(rèn)將 Offset 保存在 Kafka 一個(gè)內(nèi)置的 Topic 中,該 Topic 為 __consumer_offsets, 以支持高并發(fā)的讀寫
4總結(jié)


上面和大家一起深入探討了 Kafka 的簡(jiǎn)介, 基礎(chǔ)知識(shí)和集群架構(gòu),下一篇會(huì)從Kafka 三高(高性能, 高可用, 高并發(fā))方面來(lái)詳細(xì)闡述其巧妙的設(shè)計(jì)思想。 大家期待.....



本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。

架構(gòu)師社區(qū)

1739 篇文章

關(guān)注

發(fā)布文章

編輯精選

技術(shù)子站

關(guān)閉