前言

大家好，這里是浩道Linux，主要給大家分享Linux、Python、網(wǎng)絡(luò)通信、網(wǎng)絡(luò)安全等相關(guān)的IT知識(shí)平臺(tái)。

今天浩道跟大家分享一篇關(guān)于kafka相關(guān)原理的硬核干貨，可以說即使你沒有接觸過kafka，也可以秒懂，一起看看！

一、Kafka 基礎(chǔ)

消息系統(tǒng)的作用

應(yīng)該大部份小伙伴都清楚，用機(jī)油裝箱舉個(gè)例子

所以消息系統(tǒng)就是如上圖我們所說的倉庫，能在中間過程作為緩存，并且實(shí)現(xiàn)解耦合的作用。 引入一個(gè)場(chǎng)景，我們知道中國移動(dòng)，中國聯(lián)通，中國電信的日志處理，是交給外包去做大數(shù)據(jù)分析的，假設(shè)現(xiàn)在它們的日志都交給了你做的系統(tǒng)去做用戶畫像分析。

按照剛剛前面提到的消息系統(tǒng)的作用，我們知道了消息系統(tǒng)其實(shí)就是一個(gè)模擬緩存，且僅僅是起到了緩存的作用而并不是真正的緩存，數(shù)據(jù)仍然是存儲(chǔ)在磁盤上面而不是內(nèi)存。

1.Topic 主題

kafka 學(xué)習(xí)了數(shù)據(jù)庫里面的設(shè)計(jì)，在里面設(shè)計(jì)了topic（主題），這個(gè)東西類似于關(guān)系型數(shù)據(jù)庫的表。

此時(shí)我需要獲取中國移動(dòng)的數(shù)據(jù)，那就直接監(jiān)聽 TopicA 即可

2.Partition 分區(qū)

kafka還有一個(gè)概念叫Partition（分區(qū)），分區(qū)具體在服務(wù)器上面表現(xiàn)起初就是一個(gè)目錄，一個(gè)主題下面有多個(gè)分區(qū)，這些分區(qū)會(huì)存儲(chǔ)到不同的服務(wù)器上面，或者說，其實(shí)就是在不同的主機(jī)上建了不同的目錄。這些分區(qū)主要的信息就存在了.log文件里面。跟數(shù)據(jù)庫里面的分區(qū)差不多，是為了提高性能。

至于為什么提高了性能，很簡(jiǎn)單，多個(gè)分區(qū)多個(gè)線程，多個(gè)線程并行處理肯定會(huì)比單線程好得多

Topic 和 partition 像是 HBASE 里的 table 和 region 的概念，table 只是一個(gè)邏輯上的概念，真正存儲(chǔ)數(shù)據(jù)的是 region，這些 region 會(huì)分布式地存儲(chǔ)在各個(gè)服務(wù)器上面，對(duì)應(yīng)于kafka，也是一樣，Topic 也是邏輯概念，而 partition 就是分布式存儲(chǔ)單元。

這個(gè)設(shè)計(jì)是保證了海量數(shù)據(jù)處理的基礎(chǔ)。我們可以對(duì)比一下，如果 HDFS 沒有 block 的設(shè)計(jì)，一個(gè) 100T 的文件也只能單獨(dú)放在一個(gè)服務(wù)器上面，那就直接占滿整個(gè)服務(wù)器了，引入 block后，大文件可以分散存儲(chǔ)在不同的服務(wù)器上。

注意：

分區(qū)會(huì)有單點(diǎn)故障問題，所以我們會(huì)為每個(gè)分區(qū)設(shè)置副本數(shù)

分區(qū)的編號(hào)是從0開始的

3.Producer - 生產(chǎn)者

往消息系統(tǒng)里面發(fā)送數(shù)據(jù)的就是生產(chǎn)者

4.Consumer - 消費(fèi)者

從 kafka 里讀取數(shù)據(jù)的就是消費(fèi)者

5.Message - 消息

kafka 里面的我們處理的數(shù)據(jù)叫做消息

二、kafka的集群架構(gòu)

創(chuàng)建一個(gè) TopicA 的主題，3個(gè)分區(qū)分別存儲(chǔ)在不同的服務(wù)器，也就是 broker 下面。Topic 是一個(gè)邏輯上的概念，并不能直接在圖中把 Topic 的相關(guān)單元畫出

需要注意：kafka在0.8版本以前是沒有副本機(jī)制的，所以在面對(duì)服務(wù)器宕機(jī)的突發(fā)情況時(shí)會(huì)丟失數(shù)據(jù)，所以盡量避免使用這個(gè)版本之前的kafka

Replica - 副本

kafka 中的 partition 為了保證數(shù)據(jù)安全，所以每個(gè) partition 可以設(shè)置多個(gè)副本。 此時(shí)我們對(duì)分區(qū) 0，1，2 分別設(shè)置 3 個(gè)副本（其實(shí)設(shè)置兩個(gè)副本是比較合適的）

而且其實(shí)每個(gè)副本都是有角色之分的，它們會(huì)選取一個(gè)副本作為 leader，而其余的作為follower，我們的生產(chǎn)者在發(fā)送數(shù)據(jù)的時(shí)候，是直接發(fā)送到 leader partition 里面，然后follower partition 會(huì)去 leader 那里自行同步數(shù)據(jù)，消費(fèi)者消費(fèi)數(shù)據(jù)的時(shí)候，也是從leader那去消費(fèi)數(shù)據(jù)的。

Consumer Group - 消費(fèi)者組

我們?cè)谙M(fèi)數(shù)據(jù)時(shí)會(huì)在代碼里面指定一個(gè) group.id，這個(gè) id 代表的是消費(fèi)組的名字，而且這個(gè) group.id 就算不設(shè)置，系統(tǒng)也會(huì)默認(rèn)設(shè)置。

conf.setProperty("group.id","tellYourDream")

我們所熟知的一些消息系統(tǒng)一般來說會(huì)這樣設(shè)計(jì)，就是只要有一個(gè)消費(fèi)者去消費(fèi)了消息系統(tǒng)里面的數(shù)據(jù)，那么其余所有的消費(fèi)者都不能再去消費(fèi)這個(gè)數(shù)據(jù)。可是 kafka 并不是這樣,比如現(xiàn)在 consumerA 去消費(fèi)了一個(gè) topicA 里面的數(shù)據(jù)。

consumerA:
    group.id = a
consumerB:
    group.id = a


consumerC:
    group.id = b
consumerD:
    group.id = b

再讓 consumerB 也去消費(fèi) TopicA 的數(shù)據(jù)，它是消費(fèi)不到了，但是我們?cè)?consumerC中重新指定一個(gè)另外的 group.id，consumerC 是可以消費(fèi)到 topicA 的數(shù)據(jù)的。而consumerD 也是消費(fèi)不到的，所以在 kafka 中，不同組可有唯一的一個(gè)消費(fèi)者去消費(fèi)同一主題的數(shù)據(jù)。 所以消費(fèi)者組就是讓多個(gè)消費(fèi)者并行消費(fèi)信息而存在的，而且它們不會(huì)消費(fèi)到同一個(gè)消息，如下，consumerA，B，C是不會(huì)互相干擾的

consumer group:a
    consumerA
    consumerB
    consumerC

如圖，因?yàn)榍懊嫣岬竭^了消費(fèi)者會(huì)直接和leader建立聯(lián)系，所以它們分別消費(fèi)了三個(gè)leader，所以一個(gè)分區(qū)不會(huì)讓消費(fèi)者組里面的多個(gè)消費(fèi)者去消費(fèi)，但是在消費(fèi)者不飽和的情況下，一個(gè)消費(fèi)者是可以去消費(fèi)多個(gè)分區(qū)的數(shù)據(jù)的。

Controller

熟知一個(gè)規(guī)律：在大數(shù)據(jù)分布式文件系統(tǒng)里面，95%的都是主從式的架構(gòu)，個(gè)別是對(duì)等式的架構(gòu)，比如 ElasticSearch。 kafka也是主從式的架構(gòu)，主節(jié)點(diǎn)就叫controller，其余的為從節(jié)點(diǎn)，controller是需要和zookeeper 進(jìn)行配合管理整個(gè)kafka集群。

kafka和zookeeper如何配合工作

kafka嚴(yán)重依賴于zookeeper集群（所以之前的zookeeper文章還是有點(diǎn)用的）。所有的broker在啟動(dòng)的時(shí)候都會(huì)往zookeeper進(jìn)行注冊(cè)，目的就是選舉出一個(gè)controller，這個(gè)選舉過程非常簡(jiǎn)單粗暴，就是一個(gè)誰先誰當(dāng)?shù)倪^程，不涉及什么算法問題。 那成為controller之后要做啥呢，它會(huì)監(jiān)聽zookeeper里面的多個(gè)目錄，例如有一個(gè)目錄/brokers/，其他從節(jié)點(diǎn)往這個(gè)目錄上注冊(cè)（就是往這個(gè)目錄上創(chuàng)建屬于自己的子目錄而已）自己，這時(shí)命名規(guī)則一般是它們的id編號(hào)，比如/brokers/0，1，2 注冊(cè)時(shí)各個(gè)節(jié)點(diǎn)必定會(huì)暴露自己的主機(jī)名，端口號(hào)等等的信息，此時(shí)controller就要去讀取注冊(cè)上來的從節(jié)點(diǎn)的數(shù)據(jù)（通過監(jiān)聽機(jī)制），生成集群的元數(shù)據(jù)信息，之后把這些信息都分發(fā)給其他的服務(wù)器，讓其他服務(wù)器能感知到集群中其它成員的存在。 此時(shí)模擬一個(gè)場(chǎng)景，我們創(chuàng)建一個(gè)主題（其實(shí)就是在zookeeper上/topics/topicA這樣創(chuàng)建一個(gè)目錄而已），kafka會(huì)把分區(qū)方案生成在這個(gè)目錄中，此時(shí)controller就監(jiān)聽到了這一改變，它會(huì)去同步這個(gè)目錄的元信息，然后同樣下放給它的從節(jié)點(diǎn)，通過這個(gè)方法讓整個(gè)集群都得知這個(gè)分區(qū)方案，此時(shí)從節(jié)點(diǎn)就各自創(chuàng)建好目錄等待創(chuàng)建分區(qū)副本即可。這也是整個(gè)集群的管理機(jī)制。

加餐時(shí)間

1.Kafka性能好在什么地方？

① 順序?qū)?/p>

操作系統(tǒng)每次從磁盤讀寫數(shù)據(jù)的時(shí)候，需要先尋址，也就是先要找到數(shù)據(jù)在磁盤上的物理位置，然后再進(jìn)行數(shù)據(jù)讀寫，如果是機(jī)械硬盤，尋址就需要較長的時(shí)間。 kafka的設(shè)計(jì)中，數(shù)據(jù)其實(shí)是存儲(chǔ)在磁盤上面，一般來說，會(huì)把數(shù)據(jù)存儲(chǔ)在內(nèi)存上面性能才會(huì)好。但是kafka用的是順序?qū)懀芳訑?shù)據(jù)是追加到末尾，磁盤順序?qū)懙男阅軜O高，在磁盤個(gè)數(shù)一定，轉(zhuǎn)數(shù)達(dá)到一定的情況下，基本和內(nèi)存速度一致隨機(jī)寫的話是在文件的某個(gè)位置修改數(shù)據(jù)，性能會(huì)較低。

② 零拷貝

先來看看非零拷貝的情況

可以看到數(shù)據(jù)的拷貝從內(nèi)存拷貝到 kafka 服務(wù)進(jìn)程那塊，又拷貝到socket緩存那塊，整個(gè)過程耗費(fèi)的時(shí)間比較高，kafka 利用了 Linux 的 sendFile 技術(shù)（NIO），省去了進(jìn)程切換和一次數(shù)據(jù)拷貝，讓性能變得更好。

2.日志分段存儲(chǔ)

Kafka規(guī)定了一個(gè)分區(qū)內(nèi)的.log文件最大為1G，做這個(gè)限制目的是為了方便把.log加載到內(nèi)存去操作

00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex


00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex


00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex

3.Kafka的網(wǎng)絡(luò)設(shè)計(jì)

kafka的網(wǎng)絡(luò)設(shè)計(jì)和Kafka的調(diào)優(yōu)有關(guān)，這也是為什么它能支持高并發(fā)的原因

首先客戶端發(fā)送請(qǐng)求全部會(huì)先發(fā)送給一個(gè)Acceptor，broker里面會(huì)存在3個(gè)線程（默認(rèn)是3個(gè)），這3個(gè)線程都是叫做processor，Acceptor不會(huì)對(duì)客戶端的請(qǐng)求做任何的處理，直接封裝成一個(gè)個(gè)socketChannel發(fā)送給這些processor形成一個(gè)隊(duì)列，發(fā)送的方式是輪詢，就是先給第一個(gè)processor發(fā)送，然后再給第二個(gè)，第三個(gè)，然后又回到第一個(gè)。消費(fèi)者線程去消費(fèi)這些socketChannel時(shí)，會(huì)獲取一個(gè)個(gè)request請(qǐng)求，這些request請(qǐng)求中就會(huì)伴隨著數(shù)據(jù)。 線程池里面默認(rèn)有8個(gè)線程，這些線程是用來處理request的，解析請(qǐng)求，如果request是寫請(qǐng)求，就寫到磁盤里。讀的話返回結(jié)果。processor會(huì)從response中讀取響應(yīng)數(shù)據(jù)，然后再返回給客戶端。這就是Kafka的網(wǎng)絡(luò)三層架構(gòu)。 所以如果我們需要對(duì)kafka進(jìn)行增強(qiáng)調(diào)優(yōu)，增加processor并增加線程池里面的處理線程，就可以達(dá)到效果。request和response那一塊部分其實(shí)就是起到了一個(gè)緩存的效果，是考慮到processor們生成請(qǐng)求太快，線程數(shù)不夠不能及時(shí)處理的問題。 所以這就是一個(gè)加強(qiáng)版的reactor網(wǎng)絡(luò)線程模型。

審核編輯：湯梓紅