我們今天來聊一聊Kafka中優(yōu)秀的設(shè)計，希望可以提高你的設(shè)計能力源祈、寫代碼能力色迂！
一歇僧、kafka基礎(chǔ)
消息系統(tǒng)的作用
應(yīng)該大部份小伙伴都清楚，用機油裝箱舉個例子
所以消息系統(tǒng)就是如上圖我們所說的倉庫姑隅，能在中間過程作為緩存，并且實現(xiàn)解耦合的作用慕趴。
引入一個場景冕房，我們知道中國移動趁矾，中國聯(lián)通毫捣，中國電信的日志處理蔓同，是交給外包去做大數(shù)據(jù)分析的，假設(shè)現(xiàn)在它們的日志都交給了你做的系統(tǒng)去做用戶畫像分析弃揽。
按照剛剛前面提到的消息系統(tǒng)的作用矿微，我們知道了消息系統(tǒng)其實就是一個模擬緩存 冷冗，且僅僅是起到了緩存的作用 而并不是真正的緩存，數(shù)據(jù)仍然是存儲在磁盤上面而不是內(nèi)存拇泛。
1.Topic 主題
kafka學習了數(shù)據(jù)庫里面的設(shè)計官觅，在里面設(shè)計了topic（主題）又沾，這個東西類似于關(guān)系型數(shù)據(jù)庫的表
此時我需要獲取中國移動的數(shù)據(jù)耗跛，那就直接監(jiān)聽TopicA即可
2.Partition 分區(qū)
kafka還有一個概念叫Partition（分區(qū)）调塌，分區(qū)具體在服務(wù)器上面表現(xiàn)起初就是一個目錄，一個主題下面有多個分區(qū)负间，這些分區(qū)會存儲到不同的服務(wù)器上面政溃，或者說董虱，其實就是在不同的主機上建了不同的目錄申鱼。
這些分區(qū)主要的信息就存在了.log文件里面润讥。跟數(shù)據(jù)庫里面的分區(qū)差不多，是為了提高性能撮慨。
至于為什么提高了性能砌溺，很簡單规伐，多個分區(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的文件也只能單獨放在一個服務(wù)器上面，那就直接占滿整個服務(wù)器了盯漂，引入block后，大文件可以分散存儲在不同的服務(wù)器上就缆。
注意：
1.分區(qū)會有單點故障問題帖渠，所以我們會為每個分區(qū)設(shè)置副本數(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ū)分別存儲在不同的服務(wù)器空郊，也就是broker下面。Topic是一個邏輯上的概念 切揭，并不能直接在圖中把Topic的相關(guān)單元畫出
需要注意：kafka在0.8版本以前是沒有副本機制的狞甚，所以在面對服務(wù)器宕機的突發(fā)情況時會丟失數(shù)據(jù)，所以盡量避免使用這個版本之前的kafka
Replica - 副本
kafka中的partition為了保證數(shù)據(jù)安全廓旬，所以每個partition可以設(shè)置多個副本哼审。
此時我們對分區(qū)0,1,2分別設(shè)置3個副本（其實設(shè)置兩個副本是比較合適的）
而且其實每個副本都是有角色之分的，它們會選取一個副本作為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就算不設(shè)置芹枷，系統(tǒng)也會默認設(shè)置
conf.setProperty("group.id","tellYourDream")
我們所熟知的一些消息系統(tǒng)一般來說會這樣設(shè)計，就是只要有一個消費者去消費了消息系統(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ù)的 徘郭。
熟知一個規(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ā)給其他的服務(wù)器，讓其他服務(wù)器能感知到集群中其它成員的存在 先舷。
此時模擬一個場景艰管，我們創(chuàng)建一個主題（其實就是在zookeeper上/topics/topicA這樣創(chuàng)建一個目錄而已），kafka會把分區(qū)方案生成在這個目錄中蒋川，此時controller就監(jiān)聽到了這一改變牲芋，它會去同步這個目錄的元信息，然后同樣下放給它的從節(jié)點捺球，通過這個方法讓整個集群都得知這個分區(qū)方案缸浦，此時從節(jié)點就各自創(chuàng)建好目錄等待創(chuàng)建分區(qū)副本即可。這也是整個集群的管理機制氮兵。
加餐時間
1.Kafka性能好在什么地方裂逐？
① 順序?qū)?/p>
操作系統(tǒng)每次從磁盤讀寫數(shù)據(jù)的時候，需要先尋址胆剧，也就是先要找到數(shù)據(jù)在磁盤上的物理位置絮姆，然后再進行數(shù)據(jù)讀寫醉冤，如果是機械硬盤秩霍，尋址就需要較長的時間。
kafka的設(shè)計中蚁阳，數(shù)據(jù)其實是存儲在磁盤上面铃绒，一般來說，會把數(shù)據(jù)存儲在內(nèi)存上面性能才會好螺捐。但是kafka用的是順序?qū)懙咝芳訑?shù)據(jù)是追加到末尾矮燎，磁盤順序?qū)懙男阅軜O高，在磁盤個數(shù)一定赔癌，轉(zhuǎn)數(shù)達到一定的情況下诞外，基本和內(nèi)存速度一致
隨機寫的話是在文件的某個位置修改數(shù)據(jù)，性能會較低灾票。
② 零拷貝
先來看看非零拷貝的情況
可以看到數(shù)據(jù)的拷貝從內(nèi)存拷貝到kafka服務(wù)進程那塊峡谊，又拷貝到socket緩存那塊刊苍，整個過程耗費的時間比較高既们，kafka利用了Linux的sendFile技術(shù)（NIO），省去了進程切換和一次數(shù)據(jù)拷貝正什，讓性能變得更好啥纸。
2.日志分段存儲
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蜓席。
如果大家有看前面的兩篇有關(guān)于HDFS的文章時，就會發(fā)現(xiàn)NameNode的edits log也會做出限制课锌，所以這些框架都是會考慮到這些問題厨内。
3.Kafka的網(wǎng)絡(luò)設(shè)計
kafka的網(wǎng)絡(luò)設(shè)計和Kafka的調(diào)優(yōu)有關(guān)，這也是為什么它能支持高并發(fā)的原因
首先客戶端發(fā)送請求全部會先發(fā)送給一個Acceptor渺贤，broker里面會存在3個線程（默認是3個）雏胃，這3個線程都是叫做processor，Acceptor不會對客戶端的請求做任何的處理志鞍，直接封裝成一個個socketChannel發(fā)送給這些processor形成一個隊列瞭亮，發(fā)送的方式是輪詢，就是先給第一個processor發(fā)送固棚，然后再給第二個统翩，第三個仙蚜，然后又回到第一個。消費者線程去消費這些socketChannel時厂汗，會獲取一個個request請求委粉，這些request請求中就會伴隨著數(shù)據(jù)。
線程池里面默認有8個線程娶桦，這些線程是用來處理request的艳丛，解析請求，如果request是寫請求趟紊，就寫到磁盤里氮双。讀的話返回結(jié)果。processor會從response中讀取響應(yīng)數(shù)據(jù)霎匈，然后再返回給客戶端戴差。這就是Kafka的網(wǎng)絡(luò)三層架構(gòu)。
所以如果我們需要對kafka進行增強調(diào)優(yōu)铛嘱，增加processor并增加線程池里面的處理線程暖释，就可以達到效果。request和response那一塊部分其實就是起到了一個緩存的效果墨吓，是考慮到processor們生成請求太快球匕，線程數(shù)不夠不能及時處理的問題。
所以這就是一個加強版的reactor網(wǎng)絡(luò)線程模型帖烘。
