本篇文章將從kafka的存儲特性、生產者特性、消費者特性和消費確認這四個方面初探kafka的設計特性， 詳細內容可查看官方文檔第四章節kafka設計動機。
一、存儲特性
根據kafka官網描述，kafka的消息存儲是基於磁盤文件系統存儲的，當時我內心就留下了一個大大的❓，我們知道kafka在業界以高吞吐量和低延遲著稱，但是它的消息又是基於磁盤存儲的，那它是怎麼做到的呢？
帶着這個疑問我繼續閱讀發現，其實我讀漏了一些信息，真實是kafka消息存儲是基於磁盤文件系統和頁緩存的存儲方式。
如上圖， 是kafka消息流程示意圖，流程如下：
1.生產者把消息發送到broker的page cache中，
2.消費者根據自身存儲的offset，和partition從page cache去消費消息
3.異步線程將page cache中的消息flush到磁盤中
4.還有圖中未標註的，異步線程將page cache中的消息同步到副本上
看完以後可能會疑惑page cache是什麼？
學過操作系統我們知道操作系統的內存存儲管理方式有頁式存儲、段式存儲和段頁式存儲，在頁式存儲方式中，操作系統把內存空間按照一定大小（1，2，4k）進行劃分，劃分後的單個空間稱爲頁，理解這個概念後我們看page cache顧名思義頁緩存，可以理解成在內存中佔據4k內存的緩存空間。當生產者向消息隊列中發消息時，消息將按照順序存儲在page cache中，當page cache裝滿後，就再分配一個新的page cache。
瞭解完page cache後，我們知道其實kafka的低延遲本質上還是因爲是基於內存的，只有當消費者要消費的數據不在內存時，kafka需要去磁盤中查找數據，然後緩存到內存中，具體過程是kafka根據消費者傳的partiton key和offset信息去磁盤中把數據所在頁的數據緩存到內存中，因爲消息是順序存儲的所以消費者可以很方便訪問後面的數據。
多琢磨一下你會發現，kafka的消息存儲方式跟mysql索引的存儲方式是一樣一樣的，尋找一條數據的時候，也會把數據所在頁緩存到內存中，不同點在於mysql索引的存儲結構是B+TREE，kafka消息的存儲結構是BTREE。
當然kafka能實現消息消費的高吞吐，低延遲肯定不止上述原因，還有考慮到jvm，gc，還有linux對磁盤讀寫的優化等。
二、生產者特性
kafka集羣在接收生產者的消息時有負載均衡機制，我們知道如果對一個主題進行分區時，我們可以指定分區的數量，每個單元稱爲partition，多個partition會平均分配到各個broker上，當生產者向該主題發送消息時，kafka會根據一定算法將消息發送到一個partiton中，如hash取模算法，隨機算法等。
生產者發送消息的方式爲批處理髮送：用戶可以指定消息總數量和等待消息時間（不超過系統配置的超時時間）將一批消息統一發送到broker上。而不是一條消息接一條消息的發送，有效地提升發送效率。
除了批處理方式的話，還有同步發送，和異步發送兩種方式，跟rabbitmq的消息發送方式一樣。
三、消費者特性
kafka消費者消費消息是pull的模式，和很多消息隊列如rabbitmq的push模式不一樣。我們肯定不自覺冒出一個Why？
官方的解釋是這樣的：push模式和pull模式各有優劣。push模式很難適應消費速率不同的消費者，因爲消息發送速率是由broker決定的。push模式的目標是儘可能以最快速度傳遞消息，但是這樣很容易造成消費者來不及處理消息，典型的表現就是拒絕服務以及網絡擁塞。而pull模式則可以根據consumer的消費能力以適當的速率消費消息。pull模式還有一個優點是，它可以決定已從從broker中pull多少條消息，可以減少不必要的等待時間。同時pull模式在broker中數據爲空時使用“長輪詢”進行阻塞，知道數據到達，而不是不斷地重複輪詢佔用大量資源。
常規的消息隊列的消費模式是：broker推送消息到消費者處，消費者消費成功後給broker返回一個ack確認信息，broker收到確認信息後刪除消息
kafka消費模式是： 消費者傳partiton_id和offset給broker， broker找到對應的partition，然後根據offset找到對應的消息返回給消費者而不刪除消息，然後消費者會更新offset+n（取到的消息的數量）。直觀的看，broker有點像一個超大的消息數組，消費者根據索引去取數組中對應的值。
kafka這樣的處理模式有個好處，消費者可以根據自身情況消費隊列中的消息，如消費舊的消息。
四、消息傳遞確認
這部分跟我想象的有些出入，待更新。。。。。。。