Kafka 源碼解析之高性能架構（零）

歡迎你們關注 github.com/hsfxuebao/j… ，但願對你們有所幫助，要是以爲能夠的話麻煩給點一下Star哈

1、服務端設計

1.1服務端請求如何處理？

1.2 Reactor設計模式

1.3 高性能高併發設計

1.4 順序讀寫-高性能

Kafka是將消息記錄持久化到本地磁盤中的，通常人會認爲磁盤讀寫性能差， 對Kafka性 能如何保證提出質疑。 

實際上無論是內存仍是磁盤， 快或慢關鍵在於尋址的方式， 磁盤分爲順序讀寫與隨機讀寫， 內存也同樣分爲順序讀寫與隨機讀寫。基於磁盤的隨機讀寫確實很慢， 但磁盤的順序讀寫性能卻很高， 通常而言要高出磁盤隨機讀寫三個數量級， 一些狀況下磁盤順序讀寫性能甚至要高於內存隨機讀寫

1.5 跳錶設計

log文件：消息存儲     index文件：索引信息     成對出現

1.6 稀疏索引

1.7 零拷貝

1.7.1  非零拷貝

1.7.2 零拷貝

1.8 服務端設計總結

高併發高性能的網絡設計

順序讀寫

跳錶設計  稀疏索引  零拷貝

2、Producter設計

2.1 批處理

2.2 內存池設計

2.3 總結

批處理

內存池設計

封裝同一服務器請求

3、Consumer設計

3.1 P2P模型和發佈訂閱模型

P2P模型： 也稱點對點模型， 指同一條消息只能被一個消費者消費， 也就是說一個消息若是被這個消費者 消費了， 其他的消費者就都不能消費了， 傳統的消息系統用的就是這種方式。

 發佈訂閱模型： 容許消息被多個Consumer消費， 可是一個Consumer須要訂閱主題的全部分區。

3.2 Consumer Group設計

同一個消費組是P2P方式，一個消費只能被同一個組的一個消費者消費

不一樣組是訂閱模式，一個消息能夠被不一樣的消費組消費

一個分區同一時間只會被同組一個消費者消費

3.3 偏移量存儲

3.3.1 老版本架構方案（0.8版本）

ZK不擅長高併發操做

ZK不適合高頻讀寫操做

3.3.2 新版本的架構方案

kafka自然的支持高併發、高可用、高性能

3.4 總結

Consumer Group 的設計

偏移量存儲改造