- 在Kafka文件存儲中，同一個topic下有多個不同partition，每個partition爲一個目錄，partiton命名規則爲topic名稱+有序序號，第一個partiton序號從0開始，序號最大值爲partitions數量減1
- 在一個可配置的時間段內，Kafka集羣保留所有發佈的消息，不管這些消息有沒有被消費。比如，如果消息的保存策略被設置爲2天，那麼在一個消息被髮布的兩天時間內，它都是可以被消費的。之後它將被丟棄以釋放空間。Kafka的性能是和數據量無關的常量級的，所以保留太多的數據並不是問題。
- Kafka直接將數據寫到了文件系統的日誌中。
- Kafka高效文件存儲設計特點
- Kafka把topic中一個parition大文件分成多個小文件段，通過多個小文件段，就容易定期清除或刪除已經消費完文件，減少磁盤佔用。
- 通過索引信息可以快速定位message和確定response的最大大小。
- 通過index元數據全部映射到memory，可以避免segment file的IO磁盤操作。
- 通過索引文件稀疏存儲，可以大幅降低index文件元數據佔用空間大小。
- 消息集（message set）
- Kafka建立了“消息集（message set）”的概念，將消息組織到一起，作爲處理的單位。以消息集爲單位處理消息，比以單個的消息爲單位處理，會提升不少性能
- Producer把消息集一塊發送給服務端，而不是一條條的發送；服務端把消息集一次性的追加到日誌文件中，這樣減少了瑣碎的I/O操作
- consumer也可以一次性的請求一個消息集
- Kafka使用了標準的二進制消息格式
- zero copy
- 在一個多consumers的場景裏，數據僅僅被拷貝到頁面緩存一次而不是每次消費消息的時候都重複的進行拷貝。這使得消息以近乎網絡帶寬的速率發送出去。這樣在磁盤層面你幾乎看不到任何的讀操作，因爲數據都是從頁面緩存中直接發送到網絡上去了
- 數據壓縮
- 因爲有“消息集”的概念，客戶端的消息可以一起被壓縮後送到服務端，並以壓縮後的格式寫入日誌文件，以壓縮的格式發送到consumer，消息從producer發出到consumer拿到都被是壓縮的，只有在consumer使用的時候才被解壓縮，所以叫做“端到端的壓縮”。
- Kafka支持GZIP和Snappy壓縮協議
- Kafka判斷一個節點是否活着有兩個條件：
- 節點必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個節點的連接。
- 如果節點是個follower,他必須能及時的同步leader的寫操作，延時不能太久
- 至於延時多久算是“太久”，是由參數replica.lag.max.messages決定的，怎樣算是卡住了，怎是由參數replica.lag.time.max.ms決定的
- 只有當消息被所有的副本加入到日誌中時，纔算是“committed”，只有committed的消息纔會發送給consumer，這樣就不用擔心一旦leader down掉了消息會丟失
- Producer也可以選擇是否等待消息被提交的通知，這個是由參數request.required.acks決定的
- Kafka保證只要有一個“同步中”的節點，“committed”的消息就不會丟失。
- Kafka的核心是日誌文件，日誌文件在集羣中的同步是分佈式數據系統最基礎的要素