背景
测试环境上出现了一些entryLog解析异常的问题，想分析一下磁盘上.log文件的格式，分析分析我们的文件是否有问题
参考
bookkeeper源代码
代码地址
正文
我们采用的配置是singleEntryLog模式，就是说很多ledger的信息都会放在一个log文件内部。
插一句话：这种log文件，其实和LSM相似，属于不可变的数据结构，这种数据结构，得益于不可变，所以内容可以安排的非常紧凑，不像B树结构，需要预留一定空间给原地更新，随机插入等。
image-20210216115915838
大概如上图所示，接下来，我们沿着解析的流程，解读每个部分的详细格式
解析头部
首先，我们解析文件的头部字段，bookkeeper的设计中，文件头部预留了1024字节，目前只使用了20个字节
前四个字节是BKLO的文件魔数
然后紧跟着的4个字节是bk文件的版本号，这里我们仅分析版本号1
然后8字节的long类型代表上图中绿色部分的开始位置，称为ledgersMapOffset。
然后4字节的int类型代表绿色部分的总长度。
解析ledgerMap部分即上图中绿色部分
最前面四个字节，代表这部分的大小
然后开始的ledgerId和entryId分别为-1，-2，随后是一个ledger的count大小，后面的ledgerId和size才是有效值
随后的部分非常紧凑，由一个个ledgerId，size组成
image-20210216125728577
读取完绿色部分，可以知道，这个文件包含了多少ledger，总大小是多少？
注：size代表这一段ledger占用的磁盘空间大小
解析body内容
body内容也非常紧凑.
最前面4个字节，代表这个entry的大小。
然后8个字节，ledgerId
然后8个字节，entryId
剩下的内容，应该就是pulsar写数据的编码，不再属于bookkeeper的格式范畴了
image-20210216121801548
网友评论