《Kafka成神之路》- 索引類型
? 點(diǎn)擊上方“JavaEdge”，關(guān)注公眾號
在Kafka的數(shù)據(jù)路徑下：
.index文件，即Kafka中的位移索引文件.timeindex文件，即時間戳索引文件
不同索引類型保存不同的 K.V 對。
1 OffsetIndex - 位移索引
1.1 定義
用于根據(jù)位移值快速查找消息所在文件位置。
每當(dāng)Consumer要從topic分區(qū)的某位置開始讀消息，Kafka就會用OffsetIndex直接定位物理文件位置，避免從頭讀取消息的昂貴I/O開銷。
OffsetIndex的組成：
K，維護(hù)消息的相對偏移
V，維護(hù)該消息的日志段文件中該消息第一個字節(jié)的物理文件位置
相對偏移
AbstractIndex類中的抽象方法entrySize定義了單個K.V對所用的字節(jié)數(shù)。
OffsetIndex的entrySize就是8，如OffsetIndex.scala中定義的那樣：
相對位移是個Integer，4字節(jié)，物理文件位置也是一個Integer，4字節(jié)，因此共8字節(jié)。
Kafka的消息位移值是一個長整型（Long），應(yīng)占8字節(jié)。在保存OffsetIndex的K.V對時，Kafka做了一些優(yōu)化。每個OffsetIndex對象在創(chuàng)建時，都已保存了對應(yīng)日志段對象的起始位移，因此，OffsetIndex無需保存完整8字節(jié)位移值。實(shí)際上，只需保存與起始位移的差值，該差值整型存儲足矣。這種設(shè)計(jì)就讓OffsetIndex每個索引項(xiàng)都節(jié)省4字節(jié)。
假設(shè)某一索引文件保存1000個索引項(xiàng)，使用相對位移值就能節(jié)省大約4M。
AbstractIndex定義了relativeOffset方法
將一個Long位移值轉(zhuǎn)換成相對偏移
真正的轉(zhuǎn)換
讀取OffsetIndex時，還需將相對偏移值還原成之前的完整偏移。
parseEntry：構(gòu)造OffsetPosition所需的Key和Value
該方法返回OffsetPosition類型。因?yàn)樵擃惖膫z方法分別返回索引項(xiàng)的K、V。
physical
寫索引項(xiàng) - append
通過Long位移值和Integer物理文件位置參數(shù)，然后向mmap寫入相對位移值、物理文件位置
Truncation 截?cái)?/p>
將索引文件內(nèi)容直接裁剪掉部分。比如，OffsetIndex索引文件中當(dāng)前保存100個索引項(xiàng)，現(xiàn)在只想保留最開始40個索引項(xiàng)。
truncateToEntries
使用OffsetIndex
OffsetIndex被用來快速定位消息所在的物理文件位置，那么必然需定義一個方法執(zhí)行對應(yīng)的查詢邏輯。這個方法就是lookup。
該方法返回的，是不大于給定位移值targetOffset的最大位移值，以及對應(yīng)的物理文件位置。你大致可以把這個方法，理解為位移值的FLOOR函數(shù)。
2 TimeIndex - 時間戳索引
2.1 定義
用于根據(jù)時間戳快速查找特定消息的位移值。
TimeIndex保存<時間戳，相對位移值>對：
時間戳需長整型存儲
相對偏移值使用Integer存儲
因此，TimeIndex單個索引項(xiàng)需要占12字節(jié)。
存儲同數(shù)量索引項(xiàng)，TimeIndex比OffsetIndex占更多磁盤空間。
2.2 寫索引
maybeAppend
向TimeIndex寫索引的主體邏輯，是向mmap分別寫入時間戳和相對偏移值。
除校驗(yàn)偏移值的單調(diào)增加性之外，TimeIndex還會確保順序?qū)懭氲臅r間戳也單調(diào)增加。
不單調(diào)增加會咋樣？
向TimeIndex索引文件中寫入一個過期時間戳和位移，就會導(dǎo)致消費(fèi)端程序混亂。因?yàn)椋?dāng)消費(fèi)者端程序根據(jù)時間戳信息去過濾待讀取消息時，它讀到了這個過期時間戳并拿到錯誤位移值，于是返回錯誤數(shù)據(jù)。
3 總結(jié)及 FAQ
雖然OffsetIndex和TimeIndex是不同類型索引，但Kafka內(nèi)部把二者結(jié)合使用。通常先使用TimeIndex尋找滿足時間戳要求的消息位移值，然后再利用OffsetIndex定位該位移值所在的物理文件位置。因此，它們其實(shí)是協(xié)作關(guān)系。
二者的 broker 端參數(shù)都是log.index.size.max.bytes
為什么要一起使用，消費(fèi)者不是根據(jù)Offset找到對于位置值開始消費(fèi)就好嗎？而且結(jié)合使用性能也應(yīng)該降低？
沒錯。不過一般情況下消費(fèi)者并不是直接能夠定位目標(biāo)offset，相反地它是通過時間戳先找到目標(biāo)offset。
不要對索引文件做任何修改！擅自重命名索引文件可能導(dǎo)致Broker崩潰無法啟動的場景。雖然Kafka能重建索引，但隨意刪除索引文件真的很危險！
建立分區(qū)初始化的時候，log-segment的位移索引和時間索引文件將近有10M的數(shù)據(jù)？
里面為空，只是預(yù)分配了10MB的空間
kafka記錄消費(fèi)者的消費(fèi)offset是對消費(fèi)者組，還是對單個消費(fèi)者？比如一個消費(fèi)者組中新加入一個消費(fèi)者，分區(qū)重新分配，那新加入的消費(fèi)者是從哪里開始消費(fèi)？
針對消費(fèi)者組，或者說針對每個group id。保存的是
Kafka沒有提供延時消息機(jī)制，只能自己實(shí)現(xiàn)的哈。
往期推薦
目前交流群已有?800+人，旨在促進(jìn)技術(shù)交流，可關(guān)注公眾號添加筆者微信邀請進(jìn)群
喜歡文章，點(diǎn)個“在看、點(diǎn)贊、分享”素質(zhì)三連支持一下~