點擊上方“Java知音”，選擇“置頂公眾號”

技術(shù)文章第一時間送達(dá)！

作者：愛寶貝丶

my.oschina.net/zhangxufeng/blog/3114166

本文主要介紹kafka中日志的存儲原理，主要內(nèi)容包括kafka日志存儲格式、日志文件的管理方式、日志索引文件的格式和日志壓縮等功能。

作為一款消息系統(tǒng)，日志就是將消息持久化到磁盤上的數(shù)據(jù)，這份數(shù)據(jù)的存儲方式將會極大的影響其吞吐量和擴(kuò)展性，而kafka日志由于其優(yōu)秀的設(shè)計，為其實現(xiàn)這些特性提供了不可忽略的作用。

總結(jié)來說，kafka日志主要具有如下特點：

• 極高的壓縮比例。kafka日志不僅會對其key和value進(jìn)行壓縮，而且還會對每條消息的偏移量、時間戳等等元數(shù)據(jù)信息進(jìn)行壓縮；

• batch的方式存儲數(shù)據(jù)。在存儲上，kafka日志是以批次的方式進(jìn)行數(shù)據(jù)的存儲，每個批次的大小默認(rèn)為4KB，每個批次的元數(shù)據(jù)中會存儲其起始偏移量、時間戳和消息長度等信息；

• 追加的方式寫入數(shù)據(jù)。由于kafka日志都是寫入磁盤的，而磁盤的順序?qū)懭胄适欠浅８叩?#xff0c;kafka寫入采用的就是追加的方式寫入消息，這樣可以避免磁頭的隨機移動，從而提升寫入速率；

• 使用索引文件提升查詢性能。kafka不僅會存儲消息日志文件，還會為每個消息日志文件創(chuàng)建一個索引文件，而且索引都是以batch為單位進(jìn)行存儲的，也即只會為batch的起始位移和時間戳建立索引，而不會為每條消息都建立索引。

1. 日志存儲格式

最新版本的kafka日志是以批為單位進(jìn)行日志存儲的，所謂的批指的是kafka會將多條日志壓縮到同一個batch中，然后以batch為單位進(jìn)行后續(xù)的諸如索引的創(chuàng)建和消息的查詢等工作。

對于每個批次而言，其默認(rèn)大小為4KB，并且保存了整個批次的起始位移和時間戳等元數(shù)據(jù)信息，而對于每條消息而言，其位移和時間戳等元數(shù)據(jù)存儲的則是相對于整個批次的元數(shù)據(jù)的增量，通過這種方式，kafka能夠減少每條消息中數(shù)據(jù)占用的磁盤空間。

這里我們首先展示一下每個批次的數(shù)據(jù)格式：

圖中消息批次的每個元數(shù)據(jù)都有固定的長度大小，而只有最后面的消息個數(shù)的是可變的。如下是batch中主要的屬性的含義：

• 起始位移：占用8字節(jié)，其存儲了當(dāng)前batch中第一條消息的位移；

• 長度：占用了4個字節(jié)，其存儲了整個batch所占用的磁盤空間的大小，通過該字段，kafka在進(jìn)行消息遍歷的時候，可以快速的跳躍到下一個batch進(jìn)行數(shù)據(jù)讀取；

• 分區(qū)leader版本號：記錄了當(dāng)前消息所在分區(qū)的leader的服務(wù)器版本，主要用于進(jìn)行一些數(shù)據(jù)版本的校驗和轉(zhuǎn)換工作；

• CRC：對當(dāng)前整個batch的數(shù)據(jù)的CRC校驗碼，主要是用于對數(shù)據(jù)進(jìn)行差錯校驗的；

• 屬性：占用2個字節(jié)，這個字段的最低3位記錄了當(dāng)前batch中消息的壓縮方式，現(xiàn)在主要有GZIP、LZ4和Snappy三種。第4位記錄了時間戳的類型，第5和6位記錄了新版本引入的事務(wù)類型和控制類型；

• 最大位移增量：最新的消息的位移相對于第一條消息的唯一增量；

• 起始時間戳：占用8個字節(jié)，記錄了batch中第一條消息的時間戳；

• 最大時間戳：占用8個字節(jié)，記錄了batch中最新的一條消息的時間戳；

• PID、producer epoch和起始序列號：這三個參數(shù)主要是為了實現(xiàn)事務(wù)和冪等性而使用的，其中PID和producer epoch用于確定當(dāng)前producer是否合法，而起始序列號則主要用于進(jìn)行消息的冪等校驗；

• 消息個數(shù)：占用4個字節(jié)，記錄當(dāng)前batch中所有消息的個數(shù)；

通過上面的介紹可以看出，每個batch的頭部數(shù)據(jù)中占用的字節(jié)數(shù)固定為61個字節(jié)，可變部分主要是與具體的消息有關(guān)，下面我們來看一下batch中每條消息的格式：

這里的消息的頭部數(shù)據(jù)就與batch的大不相同，可以看到，其大部分?jǐn)?shù)據(jù)的長度都是可變的。既然是可變的，這里我們需要強調(diào)兩個問題：

1、對于數(shù)字的存儲，kafka采用的是Zig-Zag的存儲方式，也即負(fù)數(shù)并不會使用補碼的方式進(jìn)行編碼，而是將其轉(zhuǎn)換為對應(yīng)的正整數(shù)，比如-1映射為1、1映射為2、-2映射為3、2映射為4，關(guān)系圖如下所示：

通過圖可以看出，在對數(shù)據(jù)反編碼的時候，我們只需要將對應(yīng)的整數(shù)轉(zhuǎn)換成其原始值即可；

2、在使用Zig-Zag編碼方式的時候，每個字節(jié)最大為128，而其中一半要存儲正數(shù)，一半要存儲負(fù)數(shù)，還有一個0，也就是說每個字節(jié)能夠表示的最大整數(shù)為64，此時如果有大于64的數(shù)字，kafka就會使用多個字節(jié)進(jìn)行存儲。

而這多個字節(jié)的表征方式是通過將每個字節(jié)的最大位作為保留位來實現(xiàn)的，如果最高位為1，則表示需要與后續(xù)字節(jié)共同表征目標(biāo)數(shù)字，如果最高位為0，則表示當(dāng)前位即可表示目標(biāo)數(shù)字。

kafka使用這種編碼方式的優(yōu)點在于，大部分的數(shù)據(jù)增量都是非常小的數(shù)字，因此使用一個字節(jié)即可保存，這比直接使用原始類型的數(shù)據(jù)要節(jié)約大概七倍的內(nèi)存。

對于上面的每條消息的格式，除了消息key和value相關(guān)的字段，其還有屬性字段和header，屬性字段的主要作用是存儲當(dāng)前消息key和value的壓縮方式，而header則供給用戶進(jìn)行添加一些動態(tài)的屬性，從而實現(xiàn)一些定制化的工作。

通過對kafka消息日志的存儲格式我們可以看出，其使用batch的方式將一些公共信息進(jìn)行提取，從而保證其只需要存儲一份，雖然看起來每個batch的頭部信息比較多，但其平攤到每條消息上之后使用的字節(jié)更少了；

在消息層面，kafka使用了數(shù)據(jù)增量的方式和Zig-Zag編碼方式對數(shù)據(jù)進(jìn)行的壓縮，從而極大地減少其占用的字節(jié)數(shù)。總體而言，這種存儲方式極大的減少了kafka占用的磁盤空間大小。

2. 日志存儲方式

在使用kafka時，消息都是推送到某個topic中，然后由producer計算當(dāng)前消息會發(fā)送到哪個partition，在partition中，kafka會為每條消息設(shè)置一個偏移量，也就是說，如果要唯一定位一條消息，使用三元組即可。

基于kafka的架構(gòu)模式，其會將各個分區(qū)平均分配到每個broker中，也就是說每個broker會被分配用來提供一個或多個分區(qū)的日志存儲服務(wù)。在broker服務(wù)器上，kafka的日志也是按照partition進(jìn)行存儲的，其會在指定的日志存儲目錄中為每個topic的partition分別創(chuàng)建一個目錄，目錄中存儲的就是這些分區(qū)的日志數(shù)據(jù)，而目錄的名稱則會以的格式進(jìn)行創(chuàng)建。如下是kafka日志的存儲目錄示意圖：

這里我們需要注意的是，圖中對于分區(qū)日志的存儲，當(dāng)前broker只會存儲分配給其的分區(qū)的日志，比如圖中的connect-status就只有分區(qū)1和分區(qū)4的目錄，而沒有分區(qū)2和分區(qū)3的目錄，這是因為這些分區(qū)被分配在了集群的其他節(jié)點上。

在每個分區(qū)日志目錄中，存在有三種類型的日志文件，即后綴分別為log、index和timeindex的文件。其中l(wèi)og文件就是真正存儲消息日志的文件，index文件存儲的是消息的位移索引數(shù)據(jù)，而timeindex文件則存儲的是時間索引數(shù)據(jù)。

如下圖所示為一個分區(qū)的消息日志數(shù)據(jù)：

從圖中可以看出，每種類型的日志文件都是分段的，這里關(guān)于分段的規(guī)則主要有如下幾點需要說明：

• 在為日志進(jìn)行分段時，每個文件的文件名都是以該段中第一條消息的位移的偏移量來命名的；

• kafka會在每個log文件的大小達(dá)到1G的時候關(guān)閉該文件，而新開一個文件進(jìn)行數(shù)據(jù)的寫入。可以看到，圖中除了最新的log文件外，其余的log文件的大小都是1G；

• 對于index文件和timeindex文件，在每個log文件進(jìn)行分段之后，這兩個索引文件也會進(jìn)行分段，這也就是它們的文件名與log文件一致的原因；

• kafka日志的留存時間默認(rèn)是7天，也就是說，kafka會刪除存儲時間超過7天的日志，但是對于某些文件，其部分日志存儲時間未達(dá)到7天，部分達(dá)到了7天，此時還是會保留該文件，直至其所有的消息都超過留存時間；

3. 索引文件

kafka主要有兩種類型的索引文件：位移索引文件和時間戳索引文件。位移索引文件中存儲的是消息的位移與該位移所對應(yīng)的消息的物理地址；時間戳索引文件中則存儲的是消息的時間戳與該消息的位移值。

也就是說，如果需要通過時間戳查詢消息記錄，那么其首先會通過時間戳索引文件查詢該時間戳對應(yīng)的位移值，然后通過位移值在位移索引文件中查詢消息具體的物理地址。關(guān)于位移索引文件，這里有兩點需要說明：

1、由于kafka消息都是以batch的形式進(jìn)行存儲，因而索引文件中索引元素的最小單元是batch，也就是說，通過位移索引文件能夠定位到消息所在的batch，而沒法定位到消息在batch中的具體位置，查找消息的時候，還需要進(jìn)一步對batch進(jìn)行遍歷；

2、位移索引文件中記錄的位移值并不是消息真正的位移值，而是該位移相對于該位移索引文件的起始位移的偏移量，通過這種方式能夠極大的減小位移索引文件的大小。

如下圖所示為一個位移索引文件的格式示意圖：

如下則是具體的位移索引文件的示例：

關(guān)于時間戳索引文件，由于時間戳的變化比位移的變化幅度要大一些，其即使采用了增量的方式存儲時間戳索引，但也沒法有效地使用Zig-Zag方式對數(shù)據(jù)進(jìn)行編碼，因而時間戳索引文件是直接存儲的消息的時間戳數(shù)據(jù)，

但是對于時間戳索引文件中存儲的位移數(shù)據(jù)，由于其變化幅度不大，因而其還是使用相對位移的方式進(jìn)行的存儲，并且這種存儲方式也可以直接映射到位移索引文件中而無需進(jìn)行計算。如下圖所示為時間戳索引文件的格式圖：

如下則是時間戳索引文件的一個存儲示例：

可以看到，如果需要通過時間戳來定位消息，就需要首先在時間戳索引文件中定位到具體的位移，然后通過位移在位移索引文件中定位到消息的具體物理地址。

4. 日志壓縮

所謂的日志壓縮功能，其主要是針對這樣的場景的，比如對某個用戶的郵箱數(shù)據(jù)進(jìn)行修改，其總共修改了三次，修改過程如下：

email=john@gmail.com
email=john@yahoo.com.cn
email=john@163.com

在這么進(jìn)行修改之后，很明顯，我們主要需要關(guān)心的是最后一次修改，因為其是最終數(shù)據(jù)記錄，但是如果我們按順序處理上述消息，則需要處理三次消息。

kafka的日志壓縮就是為了解決這個問題而存在的，對于使用相同key的消息，其會只保留最新的一條消息的記錄，而中間過程的消息都會被kafka cleaner給清理掉。

但是需要注意的是，kafka并不會清理當(dāng)前處于活躍狀態(tài)的日志文件中的消息記錄。所謂當(dāng)前處于活躍狀態(tài)的日志文件，也就是當(dāng)前正在寫入數(shù)據(jù)的日志文件。如下圖所示為一個kafka進(jìn)行日志壓縮的示例圖：

圖中K1的數(shù)據(jù)有V1、V3和V4，經(jīng)過壓縮之后只有V4保留了下來，K2的數(shù)據(jù)則有V2、V6和V10，壓縮之后也只有V10保留了下來；同理可推斷其他的Key的數(shù)據(jù)。

另外需要注意的是，kafka開啟日志壓縮使用的是log.cleanup.policy，其默認(rèn)值為delete，也即我們正常使用的策略，如果將其設(shè)置為compaction，則開啟了日志壓縮策略，但是需要注意的是，開啟了日志壓縮策略并不代表kafka會清理歷史數(shù)據(jù)，只有將log.cleaner.enable設(shè)置為true才會定時清理歷史數(shù)據(jù)。

在kafka中，其本身也在使用日志壓縮策略，主要體現(xiàn)在kafka消息的偏移量存儲。在舊版本中，kafka將每個consumer分組當(dāng)前消費的偏移量信息保存在zookeeper中，但是由于zookeeper是一款分布式協(xié)調(diào)工具，其對于讀操作具有非常高的性能，但是對于寫操作性能比較低，而consumer的位移提交動作是非常頻繁的，這勢必會導(dǎo)致zookeeper成為kafka消息消費的瓶頸。

因而在最新版本中，kafka將分組消費的位移數(shù)據(jù)存儲在了一個特殊的topic中，即__consumer_offsets，由于每個分組group的位移信息都會提交到該topic，因而kafka默認(rèn)為其設(shè)置了非常多的分區(qū)，也即50個分區(qū)。

另外，consumer在提交位移時，使用的key為groupId+topic+partition，而值則為當(dāng)前提交的位移，也就是說，對于每一個分組所消費的topic的partition，其都只會保留最新的位移。如果consumer需要讀取位移，那么只需要按照上述格式組裝key，然后在該topic中讀取最新的消息數(shù)據(jù)即可。

5. 小結(jié)

本文首先對kafka的日志設(shè)計的優(yōu)點進(jìn)行了介紹，然后著重講解了日志存儲格式、日志目錄規(guī)劃、日志索引文件的格式以及日志壓縮的功能。

END

Java面試題專欄

【01期】Spring，SpringMVC，SpringBoot，SpringCloud有什么區(qū)別和聯(lián)系？

【02期】你能說說Spring框架中Bean的生命周期嗎？

【03期】如何決定使用 HashMap 還是 TreeMap？

【04期】分庫分表之后，id 主鍵如何處理？

【05期】消息隊列中，如何保證消息的順序性？

【06期】單例模式有幾種寫法？

【07期】Redis中是如何實現(xiàn)分布式鎖的？

【08期】說說Object類下面有幾種方法呢？

【09期】說說hashCode() 和 equals() 之間的關(guān)系？

【10期】Redis 面試常見問答

我知道你 “在看”

總結(jié)

以上是生活随笔為你收集整理的日志长度_Kafka 日志存储详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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