所以我读到这个：https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026
关于Kafka储藏室的内部结构，提出了两个问题：
索引文件中的偏移量似乎是单调增加的，那么我们为什么还要保存它呢？为什么不使用文件中行的索引作为偏移量（基于0），并将文件大小减少一半？
如果我理解正确的话，保存在日志文件中的位置就是该消息在分区中的位置（基本上是它的索引）。保存在索引文件中的位置就是那个位置，对吗？对于快速访问，例如，如果我想要分区的消息6，我在索引文件中使用二进制搜索查找6，并在同一个条目中使用偏移量，我转到日志文件中的那一行(例如，如果位置6有索引7，则转到日志文件中的第7行）
1条答案
按热度按时间zaq34kh61#
这是一个有趣的！
我对Kafka内部的理解是有限的，但无论如何，我会尝试破解它。
对于第一个问题：
我查看了offsetindex.scala的源代码-似乎索引文件中的偏移部分是在方法中计算的
relativeOffset()每次有新条目时。为了补充这一点，源代码中的描述是将偏移量Map到特定日志段的物理文件位置的索引。这个索引可能是稀疏的：也就是说，它可能不包含日志中所有消息的条目。
所以，根据你分享的参考文章-这可能是因为这个索引的稀疏性
偏移量查找使用二进制搜索来查找小于或等于目标偏移量的最近偏移量
从解释上看，偏移量似乎只是在增加——可能不一定是这样。例如，我创建了一个主题并查看了日志和索引的内容。
的内容
000---180.index文件为（注意此处的偏移量-不按顺序增加）：offset: 217 position: 4107 offset: 254 position: 8214 offset: 291 position: 12321 offset: 328 position: 16428 offset: 365 position: 20535 offset: 402 position: 24642 offset: 439 position: 28749的内容000---180.log文件为（注意此处的偏移量-按顺序增加）：[为了便于观察，我使用了3个点（…）来表示索引中可用偏移量之间的行]
offset: 217 position: 4107 CreateTime: 1537550091903 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 218 position: 4218 CreateTime: 1537550092908 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 219 position: 4329 CreateTime: 1537550093910 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 253 position: 8103 CreateTime: 1537550127960 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 254 position: 8214 CreateTime: 1537550128961 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 255 position: 8325 CreateTime: 1537550129962 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 289 position: 12099 CreateTime: 1537550164007 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 290 position: 12210 CreateTime: 1537550165008 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 291 position: 12321 CreateTime: 1537550166009 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 292 position: 12432 CreateTime: 1537550436878 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 327 position: 16317 CreateTime: 1537550471917 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 328 position: 16428 CreateTime: 1537550472919 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 329 position: 16539 CreateTime: 1537550473920 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: []关于第二个问题：我认为上面的例子应该说明这一点。是的，索引中的位置反映了段日志文件和分区中的位置。对于fetch请求，一旦在二进制搜索中找到最近的偏移量，控件就会转到段日志中的该偏移量。
我希望这有帮助！