Leveldb源码分析--5

5 操作Log 1

分析完KV在内存中的存储,接下来就是操作日志。所有的写操作都必须先成功的append到操作日志中,然后再更新内存memtable。这样做有两个有点:1可以将随机的写IO变成append,极大的提高写磁盘速度;2防止在节点down机导致内存数据丢失,造成数据丢失,这对系统来说是个灾难。

在各种高效的存储系统中,这已经是口水技术了。

5.1 格式

在源码下的文档doc/log_format.txt中,作者详细描述了log格式:
The log file contents are a sequence of 32KB blocks.  The only exception is that the tail of thefile may contain a partial block.
Each block consists of a sequence of records:
    block:= record* trailer?
    record :=
    checksum: uint32    // crc32c of type and data[] ; little-endian
    length: uint16       // little-endian
    type: uint8          // One of FULL,FIRST, MIDDLE, LAST
    data: uint8[length]
A record never starts within the last six bytes of a block (since it won'tfit).  Any leftover bytes here form thetrailer, which must consist entirely of zero bytes and must be skipped byreaders.
翻译过来就是:
Leveldb把日志文件切分成了大小为32KB的连续block块,block由连续的log record组成,log record的格式为:
,注意:CRC32, Length都是little-endian的。
Log Type有4种:FULL = 1、FIRST = 2、MIDDLE = 3、LAST = 4。FULL类型表明该log record包含了完整的user record;而user record可能内容很多,超过了block的可用大小,就需要分成几条log record,第一条类型为FIRST,中间的为MIDDLE,最后一条为LAST。也就是:
> FULL,说明该log record包含一个完整的user record;
> FIRST,说明是user record的第一条log record
> MIDDLE,说明是user record中间的log record
> LAST,说明是user record最后的一条log record
翻一下文档上的例子,考虑到如下序列的user records:
   A: length 1000
   B: length 97270
   C: length 8000
A作为FULL类型的record存储在第一个block中;B将被拆分成3条log record,分别存储在第1、2、3个block中,这时block3还剩6byte,将被填充为0;C将作为FULL类型的record存储在block 4中。如图5.1-1所示。
图5.1-1
由于一条logrecord长度最短为7,如果一个block的剩余空间<=6byte,那么将被填充为空字符串,另外长度为7的log record是不包括任何用户数据的。

5.2 写日志

写比读简单,而且写入决定了读,所以从写开始分析。

有意思的是在写文件时,Leveldb使用了内存映射文件,内存映射文件的读写效率比普通文件要高,关于内存映射文件为何更高效,这篇文章写的不错:

http://blog.csdn.net/mg0832058/article/details/5890688

其中涉及到的类层次比较简单,如图5.2-1.

图5.2-1

注意Write类的成员type_crc_数组,这里存放的为Record Type预先计算的CRC32值,因为Record Type是固定的几种,为了效率。

Writer类只有一个接口,就是AddRecord(),传入Slice参数,下面来看函数实现。

首先取出slice的字符串指针和长度,初始化begin=true,表明是第一条log record。

const char* ptr = slice.data();

size_t left = slice.size();

bool begin = true;

然后进入一个do{}while循环,直到写入出错,或者成功写入全部数据,如下:

S1 首先查看当前block是否<7,如果<7则补位,并重置block偏移。

dest_->Append(Slice("\x00\x00\x00\x00\x00\x00",leftover));

block_offset_ = 0;

S2 计算block剩余大小,以及本次log record可写入数据长度

    const size_t avail =kBlockSize - block_offset_ - kHeaderSize;

    const size_t fragment_length = (left <avail) ? left : avail;

S3 根据两个值,判断log type

    RecordType type;

    const bool end = (left ==fragment_length); // 两者相等,表明写完

    if (begin && end)  type = kFullType;

    else if (begin)     type = kFirstType;

    else if (end)       type = kLastType;

    else             type = kMiddleType;

 S4 调用EmitPhysicalRecord函数,append日志;并更新指针、剩余长度和begin标记。

    s = EmitPhysicalRecord(type, ptr,fragment_length);

    ptr += fragment_length;

    left -= fragment_length;

begin = false;

接下来看看EmitPhysicalRecord函数,这是实际写入的地方,涉及到log的存储格式。函数声明为:StatusWriter::EmitPhysicalRecord(RecordType t, const char* ptr, size_t n)

参数ptr为用户record数据,参数n为record长度,不包含log header。

S1 计算header,并Append到log文件,共7byte格式为:

| CRC32 (4 byte) | payload length lower + high (2 byte) | type (1byte)|

char buf[kHeaderSize];

  buf[4] = static_cast<char>(n& 0xff);

  buf[5] =static_cast<char>(n >> 8);

  buf[6] =static_cast<char>(t);

  // 计算record typepayloadCRC校验值

  uint32_t crc = crc32c::Extend(type_crc_[t], ptr, n);

  crc = crc32c::Mask(crc);        // 空间调整

  EncodeFixed32(buf, crc);

  dest_->Append(Slice(buf,kHeaderSize));

S2 写入payload,并Flush,更新block的当前偏移

    s =dest_->Append(Slice(ptr, n));

    s = dest_->Flush();

    block_offset_ += kHeaderSize +n;

以上就是写日志的逻辑,很直观。

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值