宏觀架構層面利用Partition實現(xiàn)并行處理

Kafka中每個Topic都包含一個或多個Partition，不同Partition可位于不同節(jié)點。

同時Partition在物理上對應一個本地文件夾，每個Partition包含一個或多個Segment，每個Segment包含一個數(shù)據(jù)文件和一個與之對應的索引文件。

一方面，由于不同Partition可位于不同機器，因此可以充分利用集群優(yōu)勢，實現(xiàn)機器間的并行處理。

另一方面，由于Partition在物理上對應一個文件夾，即使多個Partition位于同一個節(jié)點，也可通過配置讓同一節(jié)點上的不同Partition置于不同的磁盤上，從而實現(xiàn)磁盤間的并行處理，充分發(fā)揮多磁盤的優(yōu)勢。

具體實現(xiàn)層面高效使用磁盤特性和操作系統(tǒng)特性

將寫磁盤的過程變?yōu)轫樞驅?/p>

Kafka的整個設計中，Partition相當于一個非常長的數(shù)組，而Broker接收到的所有消息順序寫入這個大數(shù)組中。同時Consumer通過Offset順序消費這些數(shù)據(jù)，并且不刪除已經(jīng)消費的數(shù)據(jù)，從而避免了隨機寫磁盤的過程。

而這個刪除過程，并非通過使用“讀-寫”模式去修改文件，而是將Partition分為多個Segment，每個Segment對應一個物理文件，通過刪除整個文件的方式去刪除Partition內(nèi)的數(shù)據(jù)。這種方式清除舊數(shù)據(jù)的方式，也避免了對文件的隨機寫操作。

在存儲機制上，使用了Log Structured Merge Trees(LSM) 。

注：Log Structured Merge Trees(LSM)，谷歌 “BigTable” 的論文，中提出，LSM是當前被用在許多產(chǎn)品的文件結構策略：HBase, Cassandra, LevelDB, SQLite,Kafka。LSM被設計來提供比傳統(tǒng)的B+樹或者ISAM更好的寫操作吞吐量，通過消去隨機的本地更新操作來達到這個目標。這個問題的本質(zhì)還是磁盤隨機操作慢，順序讀寫快。這二種操作存在巨大的差距，無論是磁盤還是SSD，而且快至少三個數(shù)量級。

充分利用Page Cache

Page Cache，其中文名稱為頁高速緩沖存儲器，簡稱頁高緩。page cache的大小為一頁，通常為4K。在Linux讀寫文件時，它用于緩存文件的邏輯內(nèi)容，從而加快對磁盤上映像和數(shù)據(jù)的訪問。是Linux操作系統(tǒng)的一個特色。

• I/O Scheduler會將連續(xù)的小塊寫組裝成大塊的物理寫從而提高性能
• I/O Scheduler會嘗試將一些寫操作重新按順序排好，從而減少磁盤頭的移動時間
• 讀操作可直接在Page Cache內(nèi)進行。如果消費和生產(chǎn)速度相當，甚至不需要通過物理磁盤（直接通過Page Cache）交換數(shù)據(jù)

Kafka收到數(shù)據(jù)后，寫磁盤時只是將數(shù)據(jù)寫入Page Cache，并不保證數(shù)據(jù)一定完全寫入磁盤。

如果數(shù)據(jù)消費速度與生產(chǎn)速度相當，甚至不需要通過物理磁盤交換數(shù)據(jù)，而是直接通過Page Cache交換數(shù)據(jù)。同時，Follower從Leader Fetch數(shù)據(jù)時，也可通過Page Cache完成。

零拷貝

Kafka中存在大量的網(wǎng)絡數(shù)據(jù)持久化到磁盤（Producer到Broker）和磁盤文件通過網(wǎng)絡發(fā)送（Broker到Consumer）的過程。這一過程的性能直接影響Kafka的整體吞吐量。

而Linux 2.4+內(nèi)核通過sendfile系統(tǒng)調(diào)用，提供了零拷貝。數(shù)據(jù)通過DMA拷貝到內(nèi)核態(tài)Buffer后，直接通過DMA拷貝到NIC Buffer，無需CPU拷貝。這也是零拷貝這一說法的來源。除了減少數(shù)據(jù)拷貝外，因為整個讀文件-網(wǎng)絡發(fā)送由一個sendfile調(diào)用完成，整個過程只有兩次上下文切換，因此大大提高了性能。

總結

以上是生活随笔為你收集整理的kafka是存储到本地磁盘么_【漫画】Kafka是如何实现高性能的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。