上篇文章主要介紹了Kafka的安裝部署，以及一些簡單的命令列操作，本文我們來深入的研究一下Kafka的架構，關注專欄《破繭成蝶——大資料篇》，查看更多相關的內容~

目錄

一、Kafka作業流程

二、Kafka檔案存盤機制

三、Kafka生產者

3.1 磁區策略

3.1.1 磁區的原因

3.1.2 磁區的原則

3.2 資料可靠性

3.2.1 副本同步策略

3.2.2 ack應答機制

3.2.3 故障處理

3.3 Exactly Once語意

四、Kafka消費者

4.1 消費方式

4.2 磁區消費策略

4.3 offset的維護

五、Kafka高效讀寫資料

一、Kafka作業流程

Kafka中訊息是以topic進行分類的，生產者生產訊息，消費者消費訊息，都是面向topic的，topic是邏輯上的概念，而partition是物理上的概念，每個partition對應于一個log檔案，該log檔案中存盤的就是producer生產的資料，Producer生產的資料會被不斷追加到該log檔案末端，且每條資料都有自己的offset，消費者組中的每個消費者，都會實時記錄自己消費到了哪個offset，以便出錯恢復時，從上次的位置繼續消費，

二、Kafka檔案存盤機制

由于生產者生產的訊息會不斷追加到log檔案末尾，為防止log檔案過大導致資料定位效率低下，Kafka采取了分片和索引機制，將每個partition分為多個segment，每個segment對應兩個檔案——“.index”檔案和“.log”檔案，index和log檔案以當前segment的第一條訊息的offset命名，“.index”檔案存盤大量的索引資訊，“.log”檔案存盤大量的資料，索引檔案中的元資料指向對應資料檔案中message的物理偏移地址，

三、Kafka生產者

3.1 磁區策略

3.1.1 磁區的原因

1、方便在集群中擴展，每個Partition可以通過調整以適應它所在的機器，而一個topic又可以有多個Partition組成，因此整個集群就可以適應任意大小的資料了，2、可以提高并發，因為可以以Partition為單位讀寫了，

3.1.2 磁區的原則

需要將producer發送的資料封裝成一個ProducerRecord物件，物件內容如下圖所示：

在指明 partition 的情況下，直接將指明的值直接作為 partiton 值；在沒有指明 partition 值但有 key 的情況下，將 key 的 hash 值與 topic 的 partition 數進行取余得到 partition 值；如果既沒有 partition 值又沒有 key 值的情況下，第一次呼叫時隨機生成一個整數（后面每次呼叫在這個整數上自增），將這個值與 topic 可用的 partition 總數取余得到 partition 值，也就是常說的 round-robin 演算法，

3.2 資料可靠性

3.2.1 副本同步策略

為保證producer發送的資料，能可靠的發送到指定的topic，topic的每個partition收到producer發送的資料后，都需要向producer發送ack（acknowledgement確認收到），如果producer收到ack，就會進行下一輪的發送，否則重新發送資料，

這里有兩種方案進行副本資料的同步，如下所示：

在Kafka中，選擇第二種方式進行副本資料的同步，主要原因有以下幾點：1、同樣為了容忍n臺節點的故障，第一種方案需要2n+1個副本，而第二種方案只需要n+1個副本，而Kafka的每個磁區都有大量的資料，第一種方案會造成大量資料的冗余，2、雖然第二種方案的網路延遲會比較高，但網路延遲對Kafka的影響較小，

在選用了第二種方案后就會出現這樣一個問題：leader收到資料，所有follower都開始同步資料，但有一個follower，因為某種故障，遲遲不能與leader進行同步，那leader就要一直等下去，直到它完成同步，才能發送ack，那么這個問題要怎么解決呢？Leader維護了一個動態的in-sync replica set (ISR)，意為和leader保持同步的follower集合，當ISR中的follower完成資料的同步之后，leader就會給follower發送ack，如果follower長時間未向leader同步資料，則該follower將被踢出ISR，該時間閾值由replica.lag.time.max.ms引數設定，Leader發生故障之后，就會從ISR中選舉新的leader，

3.2.2 ack應答機制

對于某些不太重要的資料，對資料的可靠性要求不是很高，能夠容忍資料的少量丟失，所以沒必要等ISR中的follower全部接收成功，所以Kafka為用戶提供了三種可靠性級別，用戶根據對可靠性和延遲的要求進行權衡，選擇以下的配置，

0：producer不等待broker的ack，這一操作提供了一個最低的延遲，broker一接收到還沒有寫入磁盤就已經回傳，當broker故障時有可能丟失資料；

1：producer等待broker的ack，partition的leader落盤成功后回傳ack，如果在follower同步成功之前leader故障，那么將會丟失資料；

-1（all）：producer等待broker的ack，partition的leader和follower全部落盤成功后才回傳ack，但是如果在follower同步完成后，broker發送ack之前，leader發生故障，那么會造成資料重復，

3.2.3 故障處理

1、Leader故障

Leader發生故障之后，會從ISR中選出一個新的Leader，之后，為保證多個副本之間的資料一致性，其余的Follower會先將各自的log檔案高于HW的部分截掉，然后從新的Leader同步資料，注意：這只能保證副本之間的資料一致性，并不能保證資料不丟失或者不重復，其中，HW指的是所有副本中最小的LEO，LEO指的是每個副本的最后一個offset，

2、Follower故障

Follower發生故障后會被臨時踢出ISR，待該Follower恢復后，Follower會讀取本地磁盤記錄的上次的HW，并將log檔案高于HW的部分截取掉，從HW開始向Leader進行同步，等該Follower的LEO大于等于該Partition的HW，即Follower追上Leader之后，就可以重新加入ISR了，

3.3 Exactly Once語意

對于某些比較重要的訊息，我們需要保證exactly once語意，即保證每條訊息被發送且僅被發送一次，在0.11版本之后，Kafka引入了冪等性機制（idempotent），配合acks = -1時的at least once語意，實作了producer到broker的exactly once語意，使用時，只需將enable.idempotence屬性設定為true，kafka自動將acks屬性設為-1，

四、Kafka消費者

4.1 消費方式

consumer采用pull（拉）模式從broker中讀取資料，push（推）模式很難適應消費速率不同的消費者，因為訊息發送速率是由broker決定的，它的目標是盡可能以最快速度傳遞訊息，但是這樣很容易造成consumer來不及處理訊息，典型的表現就是拒絕服務以及網路擁塞，而pull模式則可以根據consumer的消費能力以適當的速率消費訊息，pull模式不足之處是，如果kafka沒有資料，消費者可能會陷入回圈中，一直回傳空資料，針對這一點，Kafka的消費者在消費資料時會傳入一個時長引數timeout，如果當前沒有資料可供消費，consumer會等待一段時間之后再回傳，這段時長即為timeout，

4.2 磁區消費策略

一個consumer group中有多個consumer，一個 topic有多個partition，所以必然會涉及到partition的分配問題，即確定那個partition由哪個consumer來消費，Kafka有兩種分配策略，一是roundrobin，一是range，

4.3 offset的維護

由于consumer在消費程序中可能會出現斷電宕機等故障，consumer恢復后，需要從故障前的位置的繼續消費，所以consumer需要實時記錄自己消費到了哪個offset，以便故障恢復后繼續消費，Kafka 0.9版本之前，consumer默認將offset保存在Zookeeper中，從0.9版本開始，consumer默認將offset保存在Kafka一個內置的topic中，該topic為__consumer_offsets，

五、Kafka高效讀寫資料

1、順序寫磁盤，Kafka的producer生產資料，要寫入到log檔案中，寫的程序是一直追加到檔案末端，為順序寫，官網有資料表明，同樣的磁盤，順序寫能到到600M/s，而隨機寫只有100k/s，這與磁盤的機械機構有關，順序寫之所以快，是因為其省去了大量磁頭尋址的時間，2、零拷貝，

本文到此已經接近尾聲了，本文主要深入講述了Kafka的架構，你們在此程序中遇到了什么問題，歡迎留言，讓我看看你們都遇到了哪些問題~