高并發(fā)場景下，Kafka如何抗住億級流量？
順序?qū)懘疟P
Kafka 之所以能夠?qū)崿F(xiàn)高吞吐量，順序?qū)懘疟P是其核心優(yōu)化策略之一。
如下圖所示：
最新文章
Partition-0
├──00000000000000000000.log
├──00000000000000000000.index
├──00000000000000000000.timeindex
├──00000000000000000100.log
├──...Kafka中每個主題分區(qū)對應一個日志文件（Log），消息以二進制形式順序?qū)懭朐撐募?/span>
并為每條消息分配唯一偏移量（offset），用于定位和順序讀取。
新的消息總是被追加到日志文件的末尾，就像寫日志一樣，只能在文件尾部添加新的記錄。
順序?qū)懭霑r，磁頭只需要很少的移動，甚至可以認為是“步進式”地寫入，避免了隨機寫入時大量的磁頭移動，從而顯著提升寫入速度。
Page Cache
Kafka 寫入消息時，并不是立刻將數(shù)據(jù)同步寫入磁盤，而是先寫入操作系統(tǒng)的 PageCache，再由操作系統(tǒng)異步刷盤。
這種設計實現(xiàn)了高吞吐 + 可持久化保障的完美平衡。
如下圖所示：
最新文章
Producer-->KafkaBroker（接收消息）-->寫入內(nèi)存頁緩存（PageCache）-->刷寫到磁盤文件（*.log）Page Cache ：是操作系統(tǒng)內(nèi)核利用空閑的物理內(nèi)存，來緩存最近訪問過的磁盤數(shù)據(jù)。
當應用程序?qū)懭胛募r，數(shù)據(jù)首先被寫入到 Page Cache 中，這個過程是在內(nèi)存中完成的，速度非常快。
為什么快？
因為寫入內(nèi)存（Page Cache），比直接寫入磁盤要快得多。
KafkaProducer 將消息發(fā)送到 Broker，Broker 將消息追加到其分區(qū)日志文件的 Page Cache 中。
從而，無需等待磁盤 I/O 完成，從而實現(xiàn)了高吞吐量的寫入。
零拷貝
當 Broker ，需要將消息發(fā)送給 Consumer 時，Kafka 利用操作系統(tǒng)的零拷貝技術（如 sendfile）。
// Kafka 的 FileRecords 類中
channel.transferTo(position, count, targetChannel);
最新文章
底層調(diào)用的就是 FileChannel.transferTo()，而這在 Linux 上最終就是 sendfile。
這允許數(shù)據(jù)直接從 Page Cache ，復制到網(wǎng)絡套接字緩沖區(qū)，而無需經(jīng)過 Kafka Broker 的用戶空間。
磁盤→內(nèi)核緩沖區(qū)→網(wǎng)卡
（中間不經(jīng)過用戶態(tài)，少兩次拷貝）從而，減少了數(shù)據(jù)拷貝的次數(shù)和上下文切換，顯著提高了網(wǎng)絡傳輸效率并降低了 CPU 開銷。
批量發(fā)送
Kafka Producer 會將多個消息打包成一個批次進行發(fā)送，Consumer 也會批量地拉取消息。
最新文章
這種批量處理的方式可以減少網(wǎng)絡請求的次數(shù)，降低網(wǎng)絡開銷，并提高吞吐量。
