Kafka分布式訊息佇列

可快速持久化。通過o(1)的磁碟資料結構提供訊息的持久化，這種結構對於即使數以tb的訊息儲存也能夠保持長時間的穩定性能

高吞吐量。即使是非常普通的硬體kafka也可以支援每秒數百萬的訊息

完全的分布式系統。它的broker、producer、consumer都原生地支援分布式，自動支援負載均衡

partition

replication

kafka將元資料儲存在zookeeper中，負責kafka集群管理，包括配置管理、動態擴充套件、broker負載均衡、leader選舉，以及 consumer group變化時的rebalance等

producer往broker發布一條訊息，broker僅僅持久化訊息

consumer主動發起pull，告訴broker乙個offset，broker把offset對應的訊息返回給consumer

kafka可以設定多久刪除和多大刪除

*.log 資料檔案

[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-8yajqkgk-1613137854778)(assets/69e4b0a6.png)]

segment檔案命名規則：partion全域性的第乙個segment從0開始，後續每個segment檔名為上乙個segment檔案最後一條訊息的offset值。數值最大為64位long大小，19位數字字元長度，沒有數字用0填充。

offset

ack + offset

即保證不重複，保證不丟失

為了解決這類問題，在producer端，當乙個訊息被傳送後，producer會等待broker傳送響應，收到響應後producer會確認訊息已經被正確傳送給kafka，否則就會重新傳送

在consumer端，因為broker記錄了partition中的offset值，這個值指向consumer下乙個消費的訊息，如果consumer收到訊息但是消費失敗，broker可以根據offset值來找到上乙個訊息，同時consumer還可以控制offset值，來對訊息進行任意處理

無需在記憶體裡維護大量的資料，kafka不需要擔心gc的問題

另外kafka直接通過sendfile系統呼叫避免了核心態和使用者態之間切換以及不必要的資料複製。

1.順序寫入

因為硬碟是機械結構，每次讀寫都會定址->寫入，其中定址是乙個「機械動作」，它是最耗時的。所以硬碟最「討厭」隨機i/o，最喜歡順序i/o。為了提高讀寫硬碟的速度，kafka就是使用順序i/o。如果乙個topic建立多個分割槽那麼每個parathion都是乙個文檔案，收到訊息後kafka會把資料插入到檔案末尾。

64位作業系統中一般可以表示20g的資料檔案，它的工作原理是直接利用作業系統的page來實現檔案到物理記憶體的直接對映。完成對映之後你對物理記憶體的操作會被同步到硬碟上。

3. kafka高效檔案儲存設計特點

kafka把topic中乙個parition大檔案分成多個小檔案段，通過多個小檔案段，就容易定期清除或刪除已經消費完檔案，減少磁碟占用。

通過索引資訊可以快速定位message和確定response的最大大小。通過index元資料全部對映到memory（記憶體對映檔案），可以避免segment file的io磁碟操作。通過索引檔案稀疏儲存，可以大幅降低index檔案元資料占用空間大小。

為了效能考慮，如果topic內的訊息只存於乙個broker，那這個broker會成為瓶頸，無法做到水平擴充套件。所以把topic內的資料分布到整個集群就是乙個自然而然的設計方式。partition的引入就是解決水平擴充套件問題的乙個方案。這樣，producer可以將資料傳送給多個broker上的多個partition，consumer也可以並行從多個broker上的不同paritition上讀資料，實現了水平擴充套件

如果乙個topic對應乙個檔案，那這個檔案所在的機器i/o將會成為這個topic的效能瓶頸，而有了partition後，不同的訊息可以並行寫入不同broker的不同partition裡，極大的提高了吞吐率。

例如讀取offset=368776的message，需要通過下面2個步驟查詢。

如果不引入segment，乙個partition直接對應乙個檔案（應該說兩個檔案，乙個資料檔案，乙個索引檔案），那這個檔案會一直增大。同時，在做data purge時，需要把檔案的前面部分給刪除，不符合kafka對檔案的順序寫優化設計方案。引入segment後，每次做data purge，只需要把舊的segment整個檔案刪除即可，保證了每個segment的順序寫

對於傳統的message queue而言，一般會刪除已經被消費的訊息，而kafka集群會保留所有的訊息，無論其被消費與否。當然，因為磁碟限制，不可能永久保留所有資料（實際上也沒必要），因此kafka提供兩種策略刪除舊資料。一是基於時間，二是基於partition檔案大小。

kafka會為每乙個consumer group保留一些metadata資訊——當前消費的訊息的position，也即offset。這個offset由consumer控制。正常情況下consumer會在消費完一條訊息後遞增該offset。當然，consumer也可將offset設成乙個較小的值，重新消費一些訊息。因為offet由consumer控制，所以kafka broker是無狀態的，它不需要標記哪些訊息被哪些消費過，也不需要通過broker去保證同乙個consumer group只有乙個consumer能消費某一條訊息，因此也就不需要鎖機制，這也為kafka的高吞吐率提供了有力保障。

參考：

分布式訊息佇列kafka

kafka是linkedin開源的分布式發布 訂閱訊息系統 訊息佇列 kafka特點 1 高吞吐率 低延遲，每秒處理幾十萬訊息，延遲最低幾毫秒 2 可擴充套件性，支援動態擴充套件節點資料 3 永續性與可靠性，資料被持久化磁碟，支援資料多副本防止資料丟失 4 高容錯，允許節點失敗 5 高併發，支援上千...

Kafka分布式訊息佇列框架

既有的訊息佇列框架或者對訊息傳送的可靠性提供了較高的保證，由此帶來較大的負擔，不能滿足海量高吞吐率的要求 或者完全面向實時訊息處理系統，對於批量離線處理的場合無法提供足夠的快取和永續性要求。如何實現 kafka的集群有多個broker伺服器組成，每個型別的訊息被定義為topic，同一topic內部的...

分布式訊息佇列

以下是訊息佇列以下的大綱，本文主要介紹訊息佇列概述，訊息佇列應用場景和訊息中介軟體示例 電商，日誌系統 訊息佇列概述 訊息佇列應用場景 訊息中介軟體示例 jms訊息服務 見第二篇 大型 架構系列 分布式訊息佇列 二 常用訊息佇列 見第二篇 大型 架構系列 分布式訊息佇列 二 參考 推薦 資料 見第二...