應(yīng)大部分的小伙伴的要求乘寒，今天這篇咱們用大白話帶你認(rèn)識 Kafka祖凫。

Kafka 基礎(chǔ)

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

大部分小伙伴應(yīng)該都清楚，這里用機(jī)油裝箱舉個例子：

image

所以消息系統(tǒng)就是如上圖我們所說的倉庫楞捂，能在中間過程作為緩存烧给，并且實現(xiàn)解耦合的作用。

image

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

Topic 主題

image

此時我需要獲取中國移動的數(shù)據(jù)延旧，那就直接監(jiān)聽 TopicA 即可谋国。

Partition 分區(qū)

Kafka 還有一個概念叫 Partition（分區(qū)），分區(qū)具體在服務(wù)器上面表現(xiàn)起初就是一個目錄迁沫。

一個主題下面有多個分區(qū)芦瘾，這些分區(qū)會存儲到不同的服務(wù)器上面，或者說集畅，其實就是在不同的主機(jī)上建了不同的目錄近弟。

image

至于為什么提高了性能，很簡單赦颇，多個分區(qū)多個線程二鳄，多個線程并行處理肯定會比單線程好得多。

Topic 和 Partition 像是 HBase 里的 Table 和 Region 的概念媒怯，Table 只是一個邏輯上的概念订讼，真正存儲數(shù)據(jù)的是 Region。

這些 Region 會分布式地存儲在各個服務(wù)器上面沪摄，對應(yīng)于 Kafka躯嫉，也是一樣纱烘，Topic 也是邏輯概念，而 Partition 就是分布式存儲單元祈餐。

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

注意：

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

• 分區(qū)的編號是從 0 開始的资锰。

Producer 生產(chǎn)者

image

Consumer 消費(fèi)者

image

Message 消息

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

Kafka 的集群架構(gòu)

創(chuàng)建一個 TopicA 的主題阶祭，3 個分區(qū)分別存儲在不同的服務(wù)器绷杜，也就是 Broker 下面。

image

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

Replica 副本

Kafka 中的 Partition 為了保證數(shù)據(jù)安全齿诉，所以每個 Partition 可以設(shè)置多個副本。

image

而且其實每個副本都是有角色之分的，它們會選取一個副本作為 Leader舀凛，而其余的作為 Follower俊扳。

image

Consumer Group 消費(fèi)者組

我們在消費(fèi)數(shù)據(jù)時會在代碼里面指定一個 group.id浸遗，這個 id 代表的是消費(fèi)組的名字弃秆，而且這個 group.id 就算不設(shè)置，系統(tǒng)也會默認(rèn)設(shè)置：

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

我們所熟知的一些消息系統(tǒng)一般來說會這樣設(shè)計，就是只要有一個消費(fèi)者去消費(fèi)了消息系統(tǒng)里面的數(shù)據(jù)，那么其余所有的消費(fèi)者都不能再去消費(fèi)這個數(shù)據(jù)。

可是 Kafka 并不是這樣，比如現(xiàn)在 ConsumerA 去消費(fèi)了一個 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)不到了，但是我們在 ConsumerC 中重新指定一個另外的 group.id，ConsumerC 是可以消費(fèi)到 TopicA 的數(shù)據(jù)的逞姿。

而 ConsumerD 也是消費(fèi)不到的栋烤，所以在 Kafka 中她渴，不同組可有唯一的一個消費(fèi)者去消費(fèi)同一主題的數(shù)據(jù)。

所以消費(fèi)者組就是讓多個消費(fèi)者并行消費(fèi)信息而存在的，而且它們不會消費(fèi)到同一個消息。

如下缠捌，ConsumerA锄贷，B，C 是不會互相干擾的：

consumer group:a
    consumerA
    consumerB
    consumerC

image

如圖曼月，因為前面提到過了消費(fèi)者會直接和 Leader 建立聯(lián)系谊却，所以它們分別消費(fèi)了三個 Leader，所以一個分區(qū)不會讓消費(fèi)者組里面的多個消費(fèi)者去消費(fèi)哑芹，但是在消費(fèi)者不飽和的情況下炎辨，一個消費(fèi)者是可以去消費(fèi)多個分區(qū)的數(shù)據(jù)的。

Controller

熟知一個規(guī)律：在大數(shù)據(jù)分布式文件系統(tǒng)里面聪姿，95% 的都是主從式的架構(gòu)碴萧，個別是對等式的架構(gòu)，比如 ElasticSearch咳燕。

Kafka 也是主從式的架構(gòu)勿决，主節(jié)點(diǎn)就叫 Controller，其余的為從節(jié)點(diǎn)招盲，Controller 是需要和 Zookeeper 進(jìn)行配合管理整個 Kafka 集群。

Kafka 和 Zookeeper 如何配合工作

Kafka 嚴(yán)重依賴于 Zookeeper 集群嘉冒，所有的 Broker 在啟動的時候都會往 Zookeeper 進(jìn)行注冊曹货，目的就是選舉出一個 Controller咆繁。

這個選舉過程非常簡單粗暴，就是一個誰先誰當(dāng)?shù)倪^程顶籽，不涉及什么算法問題玩般。

那成為 Controller 之后要做啥呢，它會監(jiān)聽 Zookeeper 里面的多個目錄礼饱，例如有一個目錄 /brokers/坏为，其他從節(jié)點(diǎn)往這個目錄上注冊（就是往這個目錄上創(chuàng)建屬于自己的子目錄而已）自己。

這時命名規(guī)則一般是它們的 id 編號镊绪，比如 /brokers/0,1,2匀伏。注冊時各個節(jié)點(diǎn)必定會暴露自己的主機(jī)名，端口號等等的信息蝴韭。

此時 Controller 就要去讀取注冊上來的從節(jié)點(diǎn)的數(shù)據(jù)（通過監(jiān)聽機(jī)制）够颠，生成集群的元數(shù)據(jù)信息，之后把這些信息都分發(fā)給其他的服務(wù)器榄鉴，讓其他服務(wù)器能感知到集群中其它成員的存在履磨。

此時模擬一個場景，我們創(chuàng)建一個主題（其實就是在 Zookeeper 上 /topics/topicA 這樣創(chuàng)建一個目錄而已）庆尘，Kafka 會把分區(qū)方案生成在這個目錄中剃诅。

此時 Controller 就監(jiān)聽到了這一改變，它會去同步這個目錄的元信息驶忌，然后同樣下放給它的從節(jié)點(diǎn)矛辕，通過這個方法讓整個集群都得知這個分區(qū)方案，此時從節(jié)點(diǎn)就各自創(chuàng)建好目錄等待創(chuàng)建分區(qū)副本即可位岔。這也是整個集群的管理機(jī)制如筛。

加餐時間

Kafka 性能好在什么地方？

①順序?qū)?/strong>

操作系統(tǒng)每次從磁盤讀寫數(shù)據(jù)的時候抒抬，需要先尋址杨刨，也就是先要找到數(shù)據(jù)在磁盤上的物理位置，然后再進(jìn)行數(shù)據(jù)讀寫擦剑，如果是機(jī)械硬盤妖胀，尋址就需要較長的時間。

Kafka 的設(shè)計中惠勒，數(shù)據(jù)其實是存儲在磁盤上面赚抡，一般來說，會把數(shù)據(jù)存儲在內(nèi)存上面性能才會好纠屋。

但是 Kafka 用的是順序?qū)懲砍迹芳訑?shù)據(jù)是追加到末尾，磁盤順序?qū)懙男阅軜O高，在磁盤個數(shù)一定赁遗，轉(zhuǎn)數(shù)達(dá)到一定的情況下署辉，基本和內(nèi)存速度一致。

隨機(jī)寫的話是在文件的某個位置修改數(shù)據(jù)岩四，性能會較低哭尝。

②零拷貝

先來看看非零拷貝的情況：

image

可以看到數(shù)據(jù)的拷貝從內(nèi)存拷貝到 Kafka 服務(wù)進(jìn)程那塊，又拷貝到 Socket 緩存那塊剖煌，整個過程耗費(fèi)的時間比較高材鹦。

Kafka 利用了 Linux 的 sendFile 技術(shù)（NIO），省去了進(jìn)程切換和一次數(shù)據(jù)拷貝耕姊，讓性能變得更好桶唐。

image

日志分段存儲

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

00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex

00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex

00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex

這個 9936472 之類的數(shù)字箩做，就是代表了這個日志段文件里包含的起始 Offset莽红，也就說明這個分區(qū)里至少都寫入了接近 1000 萬條數(shù)據(jù)了。

Kafka Broker 有一個參數(shù)邦邦，log.segment.bytes安吁，限定了每個日志段文件的大小，最大就是 1GB燃辖。

一個日志段文件滿了鬼店，就自動開一個新的日志段文件來寫入，避免單個文件過大黔龟，影響文件的讀寫性能妇智，這個過程叫做 log rolling，正在被寫入的那個日志段文件氏身，叫做 active log segment巍棱。

如果大家有了解 HDFS 就會發(fā)現(xiàn) NameNode 的 edits log 也會做出限制，所以這些框架都是會考慮到這些問題。

Kafka 的網(wǎng)絡(luò)設(shè)計

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

image

首先客戶端發(fā)送請求全部會先發(fā)送給一個 Acceptor钳降，Broker 里面會存在 3 個線程（默認(rèn)是 3 個）。

這 3 個線程都是叫做 Processor到踏，Acceptor 不會對客戶端的請求做任何的處理，直接封裝成一個個 socketChannel 發(fā)送給這些 Processor 形成一個隊列尚猿。

發(fā)送的方式是輪詢窝稿，就是先給第一個 Processor 發(fā)送，然后再給第二個凿掂，第三個伴榔，然后又回到第一個。

消費(fèi)者線程去消費(fèi)這些 socketChannel 時，會獲取一個個 Request 請求潮梯，這些 Request 請求中就會伴隨著數(shù)據(jù)骗灶。

線程池里面默認(rèn)有 8 個線程惨恭，這些線程是用來處理 Request 的秉馏，解析請求，如果 Request 是寫請求脱羡，就寫到磁盤里萝究。讀的話返回結(jié)果。

Processor 會從 Response 中讀取響應(yīng)數(shù)據(jù)锉罐，然后再返回給客戶端帆竹。這就是 Kafka 的網(wǎng)絡(luò)三層架構(gòu)。

所以如果我們需要對 Kafka 進(jìn)行增強(qiáng)調(diào)優(yōu)脓规，增加 Processor 并增加線程池里面的處理線程栽连，就可以達(dá)到效果。

Request 和 Response 那一塊部分其實就是起到了一個緩存的效果侨舆，是考慮到 Processor 們生成請求太快秒紧，線程數(shù)不夠不能及時處理的問題。

所以這就是一個加強(qiáng)版的 Reactor 網(wǎng)絡(luò)線程模型挨下。

總結(jié)

集群的搭建會再找時間去提及熔恢。這一篇簡單地從角色到一些設(shè)計的方面講述了 Kafka 的一些基礎(chǔ)，在之后的更新中會繼續(xù)逐步推進(jìn)臭笆，進(jìn)行更加深入淺出的講解叙淌。