一、Kafka基礎
消息系統的作用
應該大部份小夥伴都清楚，用機油裝箱舉個例子
創作不易，如果有一丢丢收獲，點個贊鼓勵一下吧！
整理了一份覆寫一線大廠Java面試題總結+各知識點學習思維導+一份300頁pdf文檔的Java核心知識點總結！，有需要的小夥伴們可以掃一下文末的圖檔
是以消息系統就是如上圖我們所說的倉庫，能在中間過程作為緩存，并且實作解耦合的作用。
引入一個場景，我們知道中國移動，中國聯通，中國電信的日志處理，是交給外包去做大資料分析的，假設現在它們的日志都交給了你做的系統去做使用者畫像分析。
按照剛剛前面提到的消息系統的作用，我們知道了消息系統其實就是一個模拟緩存，且僅僅是起到了緩存的作用而并不是真正的緩存，資料仍然是存儲在磁盤上面而不是記憶體。
1.Topic 主題
kafka學習了資料庫裡面的設計，在裡面設計了topic（主題），這個東西類似于關系型資料庫的表
此時我需要擷取中國移動的資料，那就直接監聽TopicA即可
2.Partition 分區
kafka還有一個概念叫Partition（分區），分區具體在伺服器上面表現起初就是一個目錄，一個主題下面有多個分區，這些分區會存儲到不同的伺服器上面，或者說，其實就是在不同的主機上建了不同的目錄。這些分區主要的資訊就存在了.log檔案裡面。跟資料庫裡面的分區差不多，是為了提高性能。
至于為什麼提高了性能，很簡單，多個分區多個線程，多個線程并行處理肯定會比單線程好得多
Topic和partition像是HBASE裡的table和region的概念，table隻是一個邏輯上的概念，真正存儲資料的是region，這些region會分布式地存儲在各個伺服器上面，對應于kafka，也是一樣，Topic也是邏輯概念，而partition就是分布式存儲單元。這個設計是保證了海量資料處理的基礎。我們可以對比一下，如果HDFS沒有block的設計，一個100T的檔案也隻能單獨放在一個伺服器上面，那就直接占滿整個伺服器了，引入block後，大檔案可以分散存儲在不同的伺服器上。
注意：1.分區會有單點故障問題，是以我們會為每個分區設定副本數
2.分區的編号是從0開始的
3.Producer - 生産者
往消息系統裡面發送資料的就是生産者
4.Consumer - 消費者
從kafka裡讀取資料的就是消費者
5.Message - 消息
kafka裡面的我們處理的資料叫做消息
二、kafka的叢集架構
建立一個TopicA的主題，3個分區分别存儲在不同的伺服器，也就是broker下面。Topic是一個邏輯上的概念，并不能直接在圖中把Topic的相關單元畫出
創作不易，如果有一丢丢收獲，點個贊鼓勵一下吧！
整理了一份覆寫一線大廠Java面試題總結+各知識點學習思維導+一份300頁pdf文檔的Java核心知識點總結！，有需要的小夥伴們可以掃一下下面的圖檔
需要注意：kafka在0.8版本以前是沒有副本機制的，是以在面對伺服器當機的突發情況時會丢失資料，是以盡量避免使用這個版本之前的kafka
Replica - 副本
kafka中的partition為了保證資料安全，是以每個partition可以設定多個副本。
此時我們對分區0,1,2分别設定3個副本（其實設定兩個副本是比較合适的）
而且其實每個副本都是有角色之分的，它們會選取一個副本作為leader，而其餘的作為follower，我們的生産者在發送資料的時候，是直接發送到leader partition裡面，然後follower partition會去leader那裡自行同步資料，消費者消費資料的時候，也是從leader那去消費資料的。
Consumer Group - 消費者組
我們在消費資料時會在代碼裡面指定一個group.id,這個id代表的是消費組的名字，而且這個group.id就算不設定，系統也會預設設定
conf.setProperty("group.id","tellYourDream") 我們所熟知的一些消息系統一般來說會這樣設計，就是隻要有一個消費者去消費了消息系統裡面的資料，那麼其餘所有的消費者都不能再去消費這個資料。可是kafka并不是這樣,比如現在consumerA去消費了一個topicA裡面的資料。
consumerA:
group.id = a
consumerB:
group.id = a
consumerC:
group.id = b
consumerD:
group.id = b 再讓consumerB也去消費TopicA的資料，它是消費不到了，但是我們在consumerC中重新指定一個另外的group.id，consumerC是可以消費到topicA的資料的。而consumerD也是消費不到的，是以在kafka中，不同組可有唯一的一個消費者去消費同一主題的資料。
是以消費者組就是讓多個消費者并行消費資訊而存在的，而且它們不會消費到同一個消息，如下，consumerA，B，C是不會互相幹擾的
consumer group:a
consumerA
consumerB
consumerC 如圖，因為前面提到過了消費者會直接和leader建立聯系，是以它們分别消費了三個leader，是以一個分區不會讓消費者組裡面的多個消費者去消費，但是在消費者不飽和的情況下，一個消費者是可以去消費多個分區的資料的。
Controller
熟知一個規律：在大資料分布式檔案系統裡面，95%的都是主從式的架構，個别是對等式的架構，比如ElasticSearch。
kafka也是主從式的架構，主節點就叫controller，其餘的為從節點，controller是需要和zookeeper進行配合管理整個kafka叢集。
kafka和zookeeper如何配合工作
kafka嚴重依賴于zookeeper叢集（是以之前的zookeeper文章還是有點用的）。所有的broker在啟動的時候都會往zookeeper進行注冊，目的就是選舉出一個controller，這個選舉過程非常簡單粗暴，就是一個誰先誰當的過程，不涉及什麼算法問題。
那成為controller之後要做啥呢，它會監聽zookeeper裡面的多個目錄，例如有一個目錄/brokers/，其他從節點往這個目錄上**注冊（就是往這個目錄上建立屬于自己的子目錄而已）**自己，這時命名規則一般是它們的id編号，比如/brokers/0,1,2
注冊時各個節點必定會暴露自己的主機名，端口号等等的資訊，此時controller就要去讀取注冊上來的從節點的資料（通過監聽機制），生成叢集的中繼資料資訊，之後把這些資訊都分發給其他的伺服器，讓其他伺服器能感覺到叢集中其它成員的存在。
此時模拟一個場景，我們建立一個主題（其實就是在zookeeper上/topics/topicA這樣建立一個目錄而已），kafka會把分區方案生成在這個目錄中，此時controller就監聽到了這一改變，它會去同步這個目錄的元資訊，然後同樣下放給它的從節點，通過這個方法讓整個叢集都得知這個分區方案，此時從節點就各自建立好目錄等待建立分區副本即可。這也是整個叢集的管理機制。
加餐時間
1.Kafka性能好在什麼地方？
① 順序寫
作業系統每次從磁盤讀寫資料的時候，需要先尋址，也就是先要找到資料在磁盤上的實體位置，然後再進行資料讀寫，如果是機械硬碟，尋址就需要較長的時間。 kafka的設計中，資料其實是存儲在磁盤上面，一般來說，會把資料存儲在記憶體上面性能才會好。但是kafka用的是順序寫，追加資料是追加到末尾，磁盤順序寫的性能極高，在磁盤個數一定，轉數達到一定的情況下，基本和記憶體速度一緻
随機寫的話是在檔案的某個位置修改資料，性能會較低。
② 零拷貝
先來看看非零拷貝的情況
可以看到資料的拷貝從記憶體拷貝到kafka服務程序那塊，又拷貝到socket緩存那塊，整個過程耗費的時間比較高，kafka利用了Linux的sendFile技術（NIO），省去了程序切換和一次資料拷貝，讓性能變得更好。
2.日志分段存儲
Kafka規定了一個分區内的.log檔案最大為1G，做這個限制目的是為了友善把.log加載到記憶體去操作
00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex
00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex
00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex 這個9936472之類的數字，就是代表了這個日志段檔案裡包含的起始offset，也就說明這個分區裡至少都寫入了接近1000萬條資料了。Kafka broker有一個參數，log.segment.bytes，限定了每個日志段檔案的大小，最大就是1GB，一個日志段檔案滿了，就自動開一個新的日志段檔案來寫入，避免單個檔案過大，影響檔案的讀寫性能，這個過程叫做log rolling，正在被寫入的那個日志段檔案，叫做active log segment。
如果大家有看前面的兩篇有關于HDFS的文章時，就會發現NameNode的edits log也會做出限制，是以這些架構都是會考慮到這些問題。
3.Kafka的網絡設計
kafka的網絡設計和Kafka的調優有關，這也是為什麼它能支援高并發的原因
首先用戶端發送請求全部會先發送給一個Acceptor，broker裡面會存在3個線程（預設是3個），這3個線程都是叫做processor，Acceptor不會對用戶端的請求做任何的處理，直接封裝成一個個socketChannel發送給這些processor形成一個隊列，發送的方式是輪詢，就是先給第一個processor發送，然後再給第二個，第三個，然後又回到第一個。消費者線程去消費這些socketChannel時，會擷取一個個request請求，這些request請求中就會伴随着資料。
線程池裡面預設有8個線程，這些線程是用來處理request的，解析請求，如果request是寫請求，就寫到磁盤裡。讀的話傳回結果。 processor會從response中讀取響應資料，然後再傳回給用戶端。這就是Kafka的網絡三層架構。
是以如果我們需要對kafka進行增強調優，增加processor并增加線程池裡面的處理線程，就可以達到效果。request和response那一塊部分其實就是起到了一個緩存的效果，是考慮到processor們生成請求太快，線程數不夠不能及時處理的問題。
是以這就是一個加強版的reactor網絡線程模型。
finally
叢集的搭建會再找時間去提及。這一篇簡單地從角色到一些設計的方面講述了Kafka的一些基礎，在之後的更新中會繼續逐漸推進，進行更加深入淺出的講解。
創作不易，如果有一丢丢收獲，點個贊鼓勵一下吧！
整理了一份覆寫一線大廠Java面試題總結+各知識點學習思維導+一份300頁pdf文檔的Java核心知識點總結！，有需要的小夥伴們可以掃一下下面的圖檔