kafka内存不断增加_分布式发布订阅消息系统Kafka 为什么快
Kafka 為什么能那么快 | Kafka高效讀寫數據的原因
無論 kafka 作為 MQ 也好，作為存儲層也罷，無非就是兩個功能(好簡單的樣子)，一是 Producer 生產的數據存到 broker，二是 Consumer 從 broker 讀取數據。那 Kafka 的快也就體現在讀寫兩個方面了，下面我們就聊聊 Kafka 快的原因。
1. 利用 Partition 實現并行處理
我們都知道 Kafka 是一個 Pub-Sub 的消息系統，無論是發布還是訂閱，都要指定 Topic。
Topic 只是一個邏輯的概念。每個 Topic 都包含一個或多個 Partition，不同 Partition 可位于不同節點。
一方面，由于不同 Partition 可位于不同機器，因此可以充分利用集群優勢，實現機器間的并行處理。另一方面，由于 Partition 在物理上對應一個文件夾，即使多個 Partition 位于同一個節點，也可通過配置讓同一節點上的不同 Partition 置于不同的磁盤上，從而實現磁盤間的并行處理，充分發揮多磁盤的優勢。
能并行處理，速度肯定會有提升，多個工人肯定比一個工人干的快。
可以并行寫入不同的磁盤？那磁盤讀寫的速度可以控制嗎？
那就先簡單扯扯磁盤/IO 的那些事
硬盤性能的制約因素是什么？如何根據磁盤I/O特性來進行系統設計？
硬盤內部主要部件為磁盤盤片、傳動手臂、讀寫磁頭和主軸馬達。實際數據都是寫在盤片上，讀寫主要是通過傳動手臂上的讀寫磁頭來完成。實際運行時，主軸讓磁盤盤片轉動，然后傳動手臂可伸展讓讀取頭在盤片上進行讀寫操作。磁盤物理結構如下圖所示：
由于單一盤片容量有限，一般硬盤都有兩張以上的盤片，每個盤片有兩面，都可記錄信息，所以一張盤片對應著兩個磁頭。盤片被分為許多扇形的區域，每個區域叫一個扇區。盤片表面上以盤片中心為圓心，不同半徑的同心圓稱為磁道，不同盤片相同半徑的磁道所組成的圓柱稱為柱面。磁道與柱面都是表示不同半徑的圓，在許多場合，磁道和柱面可以互換使用。磁盤盤片垂直視角如下圖所示：
圖片來源：commons.wikimedia.org影響磁盤的關鍵因素是磁盤服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。
機械硬盤的連續讀寫性能很好，但隨機讀寫性能很差，這主要是因為磁頭移動到正確的磁道上需要時間，隨機讀寫時，磁頭需要不停的移動，時間都浪費在了磁頭尋址上，所以性能不高。衡量磁盤的重要主要指標是IOPS和吞吐量。
在許多的開源框架如 Kafka、HBase 中，都通過追加寫的方式來盡可能的將隨機 I/O 轉換為順序 I/O，以此來降低尋址時間和旋轉延時，從而最大限度的提高 IOPS。
感興趣的同學可以看看?磁盤I/O那些事
磁盤讀寫的快慢取決于你怎么使用它，也就是順序讀寫或者隨機讀寫。
2. 順序寫磁盤
圖片來源：kafka.apache.orgKafka 中每個分區是一個有序的，不可變的消息序列，新的消息不斷追加到 partition 的末尾，這個就是順序寫。
很久很久以前就有人做過基準測試：《每秒寫入2百萬(在三臺廉價機器上)》http://ifeve.com/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines/
由于磁盤有限，不可能保存所有數據，實際上作為消息系統 Kafka 也沒必要保存所有數據，需要刪除舊的數據。又由于順序寫入的原因，所以 Kafka 采用各種刪除策略刪除數據的時候，并非通過使用“讀 - 寫”模式去修改文件，而是將 Partition 分為多個 Segment，每個 Segment 對應一個物理文件，通過刪除整個文件的方式去刪除 Partition 內的數據。這種方式清除舊數據的方式，也避免了對文件的隨機寫操作。
3. 充分利用 Page Cache
引入 Cache 層的目的是為了提高 Linux 操作系統對磁盤訪問的性能。Cache 層在內存中緩存了磁盤上的部分數據。當數據的請求到達時，如果在 Cache 中存在該數據且是最新的，則直接將數據傳遞給用戶程序，免除了對底層磁盤的操作，提高了性能。Cache 層也正是磁盤 IOPS 為什么能突破 200 的主要原因之一。
在 Linux 的實現中，文件 Cache 分為兩個層面，一是 Page Cache，另一個 Buffer Cache，每一個 Page Cache 包含若干 Buffer Cache。Page Cache 主要用來作為文件系統上的文件數據的緩存來用，尤其是針對當進程對文件有 read/write 操作的時候。Buffer Cache 則主要是設計用來在系統對塊設備進行讀寫的時候，對塊進行數據緩存的系統來使用。
使用 Page Cache 的好處：
I/O Scheduler 會將連續的小塊寫組裝成大塊的物理寫從而提高性能
I/O Scheduler 會嘗試將一些寫操作重新按順序排好，從而減少磁盤頭的移動時間
充分利用所有空閑內存(非 JVM 內存)。如果使用應用層 Cache(即 JVM 堆內存)，會增加 GC 負擔
讀操作可直接在 Page Cache 內進行。如果消費和生產速度相當，甚至不需要通過物理磁盤(直接通過 Page Cache)交換數據
如果進程重啟，JVM 內的 Cache 會失效，但 Page Cache 仍然可用
Broker 收到數據后，寫磁盤時只是將數據寫入 Page Cache，并不保證數據一定完全寫入磁盤。從這一點看，可能會造成機器宕機時，Page Cache 內的數據未寫入磁盤從而造成數據丟失。但是這種丟失只發生在機器斷電等造成操作系統不工作的場景，而這種場景完全可以由 Kafka 層面的 Replication 機制去解決。如果為了保證這種情況下數據不丟失而強制將 Page Cache 中的數據 Flush 到磁盤，反而會降低性能。也正因如此，Kafka 雖然提供了?flush.messages?和?flush.ms?兩個參數將 Page Cache 中的數據強制 Flush 到磁盤，但是 Kafka 并不建議使用。
4. 零拷貝技術
Kafka 中存在大量的網絡數據持久化到磁盤(Producer 到 Broker)和磁盤文件通過網絡發送(Broker 到 Consumer)的過程。這一過程的性能直接影響 Kafka 的整體吞吐量。
操作系統的核心是內核，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的權限。
為了避免用戶進程直接操作內核，保證內核安全，操作系統將虛擬內存劃分為兩部分，一部分是內核空間(Kernel-space)，一部分是用戶空間(User-space)。
傳統的 Linux 系統中，標準的 I/O 接口(例如read，write)都是基于數據拷貝操作的，即 I/O 操作會導致數據在內核地址空間的緩沖區和用戶地址空間的緩沖區之間進行拷貝，所以標準 I/O 也被稱作緩存 I/O。這樣做的好處是，如果所請求的數據已經存放在內核的高速緩沖存儲器中，那么就可以減少實際的 I/O 操作，但壞處就是數據拷貝的過程，會導致 CPU 開銷。
我們把 Kafka 的生產和消費簡化成如下兩個過程來看：
網絡數據持久化到磁盤 (Producer 到 Broker)
磁盤文件通過網絡發送(Broker 到 Consumer)
4.1 網絡數據持久化到磁盤 (Producer 到 Broker)
傳統模式下，數據從網絡傳輸到文件需要 4 次數據拷貝、4 次上下文切換和兩次系統調用。
data?=?socket.read()//?讀取網絡數據?File?file?=?new?File()?
file.write(data)//?持久化到磁盤?
file.flush()
這一過程實際上發生了四次數據拷貝：
首先通過 DMA copy 將網絡數據拷貝到內核態 Socket Buffer
然后應用程序將內核態 Buffer 數據讀入用戶態(CPU copy)
接著用戶程序將用戶態 Buffer 再拷貝到內核態(CPU copy)
最后通過 DMA copy 將數據拷貝到磁盤文件
DMA(Direct Memory Access)：直接存儲器訪問。DMA 是一種無需 CPU 的參與，讓外設和系統內存之間進行雙向數據傳輸的硬件機制。使用 DMA 可以使系統 CPU 從實際的 I/O 數據傳輸過程中擺脫出來，從而大大提高系統的吞吐率。
同時，還伴隨著四次上下文切換，如下圖所示
數據落盤通常都是非實時的，kafka 生產者數據持久化也是如此。Kafka 的數據并不是實時的寫入硬盤，它充分利用了現代操作系統分頁存儲來利用內存提高 I/O 效率，就是上一節提到的 Page Cache。
對于 kafka 來說，Producer 生產的數據存到 broker，這個過程讀取到 socket buffer 的網絡數據，其實可以直接在內核空間完成落盤。并沒有必要將 socket buffer 的網絡數據，讀取到應用進程緩沖區；在這里應用進程緩沖區其實就是 broker，broker 收到生產者的數據，就是為了持久化。
在此特殊場景下：接收來自 socket buffer 的網絡數據，應用進程不需要中間處理、直接進行持久化時。可以使用 mmap 內存文件映射。
Memory Mapped Files：簡稱 mmap，也有叫?MMFile?的，使用 mmap 的目的是將內核中讀緩沖區(read buffer)的地址與用戶空間的緩沖區(user buffer)進行映射。從而實現內核緩沖區與應用程序內存的共享，省去了將數據從內核讀緩沖區(read buffer)拷貝到用戶緩沖區(user buffer)的過程。它的工作原理是直接利用操作系統的 Page 來實現文件到物理內存的直接映射。完成映射之后你對物理內存的操作會被同步到硬盤上。
使用這種方式可以獲取很大的 I/O 提升，省去了用戶空間到內核空間復制的開銷。
mmap 也有一個很明顯的缺陷——不可靠，寫到 mmap 中的數據并沒有被真正的寫到硬盤，操作系統會在程序主動調用 flush 的時候才把數據真正的寫到硬盤。Kafka 提供了一個參數——producer.type?來控制是不是主動flush；如果 Kafka 寫入到 mmap 之后就立即 flush 然后再返回 Producer 叫同步(sync)；寫入 mmap 之后立即返回 Producer 不調用 flush 就叫異步(async)，默認是 sync。
零拷貝(Zero-copy)技術指在計算機執行操作時，CPU 不需要先將數據從一個內存區域復制到另一個內存區域，從而可以減少上下文切換以及 CPU 的拷貝時間。
它的作用是在數據報從網絡設備到用戶程序空間傳遞的過程中，減少數據拷貝次數，減少系統調用，實現 CPU 的零參與，徹底消除 CPU 在這方面的負載。
目前零拷貝技術主要有三種類型：
直接I/O：數據直接跨過內核，在用戶地址空間與I/O設備之間傳遞，內核只是進行必要的虛擬存儲配置等輔助工作；
避免內核和用戶空間之間的數據拷貝：當應用程序不需要對數據進行訪問時，則可以避免將數據從內核空間拷貝到用戶空間
mmap
sendfile
splice && tee
sockmap
copy on write：寫時拷貝技術，數據不需要提前拷貝，而是當需要修改的時候再進行部分拷貝。
4.2 磁盤文件通過網絡發送(Broker 到 Consumer)
傳統方式實現：先讀取磁盤、再用 socket 發送，實際也是進過四次 copy
buffer?=?File.read?Socket.send(buffer)
這一過程可以類比上邊的生產消息：
首先通過系統調用將文件數據讀入到內核態 Buffer(DMA 拷貝)
然后應用程序將內存態 Buffer 數據讀入到用戶態 Buffer(CPU 拷貝)
接著用戶程序通過 Socket 發送數據時將用戶態 Buffer 數據拷貝到內核態 Buffer(CPU 拷貝)
最后通過 DMA 拷貝將數據拷貝到 NIC Buffer
Linux 2.4+ 內核通過 sendfile 系統調用，提供了零拷貝。數據通過 DMA 拷貝到內核態 Buffer 后，直接通過 DMA 拷貝到 NIC Buffer，無需 CPU 拷貝。這也是零拷貝這一說法的來源。除了減少數據拷貝外，因為整個讀文件 - 網絡發送由一個 sendfile 調用完成，整個過程只有兩次上下文切換，因此大大提高了性能。
Kafka 在這里采用的方案是通過 NIO 的?transferTo/transferFrom?調用操作系統的 sendfile 實現零拷貝。總共發生 2 次內核數據拷貝、2 次上下文切換和一次系統調用，消除了 CPU 數據拷貝
5. 批處理
在很多情況下，系統的瓶頸不是 CPU 或磁盤，而是網絡IO。
因此，除了操作系統提供的低級批處理之外，Kafka 的客戶端和 broker 還會在通過網絡發送數據之前，在一個批處理中累積多條記錄 (包括讀和寫)。記錄的批處理分攤了網絡往返的開銷，使用了更大的數據包從而提高了帶寬利用率。
6. 數據壓縮
Producer 可將數據壓縮后發送給 broker，從而減少網絡傳輸代價，目前支持的壓縮算法有：Snappy、Gzip、LZ4。數據壓縮一般都是和批處理配套使用來作為優化手段的。
小總結 | 下次面試官問我 kafka 為什么快，我就這么說
partition 并行處理
順序寫磁盤，充分利用磁盤特性
利用了現代操作系統分頁存儲 Page Cache 來利用內存提高 I/O 效率
采用了零拷貝技術
Producer 生產的數據持久化到 broker，采用 mmap 文件映射，實現順序的快速寫入
Customer 從 broker 讀取數據，采用 sendfile，將磁盤文件讀到 OS 內核緩沖區后，轉到 NIO buffer進行網絡發送，減少 CPU 消耗
出處：https://www.cnblogs.com/lazyegg/p/13501809.html
版權申明：本文來源于網友收集或網友提供，如果有侵權，請轉告版主或者留言，本公眾號立即刪除。
總結
以上是生活随笔為你收集整理的kafka内存不断增加_分布式发布订阅消息系统Kafka 为什么快的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： NuxtJS快速入门
- 下一篇： React Native windows