大白話聊聊 Kafka 的架構(gòu)原理和網(wǎng)絡設計，它的性能高在什么地方？

一、Kafka基礎

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

應該大部分小伙伴都清楚，用機油裝箱舉個例子：

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

引入一個場景，我們知道中國移動，中國聯(lián)通，中國電信的日志處理，是交給外包去做大數(shù)據(jù)分析的，假設現(xiàn)在它們的日志都交給了你做的系統(tǒng)去做用戶畫像分析。

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

1.Topic 主題

kafka學習了數(shù)據(jù)庫里面的設計，在里面設計了topic（主題），這個東西類似于關系型數(shù)據(jù)庫的表。

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

2.Partition 分區(qū)

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

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

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

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

注意：

1. 分區(qū)會有單點故障問題，所以我們會為每個分區(qū)設置副本數(shù)

2. 分區(qū)的編號是從0開始的

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

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

4.Consumer - 消費者

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

5.Message - 消息

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

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

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

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

Replica - 副本

kafka中的partition為了保證數(shù)據(jù)安全，所以每個partition可以設置多個副本。

此時我們對分區(qū)0,1,2分別設置3個副本（其實設置兩個副本是比較合適的）

而且其實每個副本都是有角色之分的，它們會選取一個副本作為leader，而其余的作為follower，我們的生產(chǎn)者在發(fā)送數(shù)據(jù)的時候，是直接發(fā)送到leader partition里面。

然后follower partition會去leader那里自行同步數(shù)據(jù)，消費者消費數(shù)據(jù)的時候，也是從leader那去消費數(shù)據(jù)的。

Consumer Group - 消費者組

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

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

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

可是kafka并不是這樣,比如現(xiàn)在consumerA去消費了一個topicA里面的數(shù)據(jù)。

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

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

再讓consumerB也去消費TopicA的數(shù)據(jù)，它是消費不到了，但是我們在consumerC中重新指定一個另外的group.id，consumerC是可以消費到topicA的數(shù)據(jù)的。而consumerD也是消費不到的，所以在kafka中，不同組可有唯一的一個消費者去消費同一主題的數(shù)據(jù)。

所以消費者組就是讓多個消費者并行消費信息而存在的，而且它們不會消費到同一個消息，如下，consumerA，B，C是不會互相干擾的

consumer group:a
    consumerA
    consumerB
    consumerC

因為前面提到過了消費者會直接和leader建立聯(lián)系，所以它們分別消費了三個leader，所以一個分區(qū)不會讓消費者組里面的多個消費者去消費，但是在消費者不飽和的情況下，一個消費者是可以去消費多個分區(qū)的數(shù)據(jù)的。

Controller

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

kafka也是主從式的架構(gòu)，主節(jié)點就叫controller，其余的為從節(jié)點，controller是需要和zookeeper進行配合管理整個kafka集群。

kafka和zookeeper如何配合工作

kafka嚴重依賴于zookeeper集群（所以之前的zookeeper文章還是有點用的）。

所有的broker在啟動的時候都會往zookeeper進行注冊，目的就是選舉出一個controller，這個選舉過程非常簡單粗暴，就是一個誰先誰當?shù)倪^程，不涉及什么算法問題。

那成為controller之后要做啥呢，它會監(jiān)聽zookeeper里面的多個目錄，例如有一個目錄/brokers/，其他從節(jié)點往這個目錄上注冊（就是往這個目錄上創(chuàng)建屬于自己的子目錄而已）自己，這時命名規(guī)則一般是它們的id編號，比如/brokers/0,1,2

注冊時各個節(jié)點必定會暴露自己的主機名，端口號等等的信息，此時controller就要去讀取注冊上來的從節(jié)點的數(shù)據(jù)（通過監(jiān)聽機制），生成集群的元數(shù)據(jù)信息，之后把這些信息都分發(fā)給其他的服務器，讓其他服務器能感知到集群中其它成員的存在。

此時模擬一個場景，我們創(chuàng)建一個主題（其實就是在zookeeper上/topics/topicA這樣創(chuàng)建一個目錄而已），kafka會把分區(qū)方案生成在這個目錄中，此時controller就監(jiān)聽到了這一改變，它會去同步這個目錄的元信息，然后同樣下放給它的從節(jié)點，通過這個方法讓整個集群都得知這個分區(qū)方案，此時從節(jié)點就各自創(chuàng)建好目錄等待創(chuàng)建分區(qū)副本即可。這也是整個集群的管理機制。

加餐時間

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

① 順序?qū)?/strong>

00000000000000000000.index 00000000000000000000.log 00000000000000000000.timeindex 00000000000005367851.index 00000000000005367851.log 00000000000005367851.timeindex 00000000000009936472.index 00000000000009936472.log 00000000000009936472.timeindex 

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
																			

																				

																				

																					
																				


																			
長按訂閱更多精彩▼
																				

																			
如有收獲，點個在看，誠摯感謝