上一节中，我们知道，SequenceNumber使得对写入的任何key在内部存储时都会附加一个递增的SequenceNumber。而在leveldb内部，一次snapshot也对应一个全局唯一的SequenceNumber。因此，在调用GetSnapshot获取snapshot时，leveldb所做的仅仅是生成一个SequenceNumber。db内部使用双向循环链表保存先后生成的snapshot。获取快照GetSnapshot会将新snapshot加入链表，而释放快照ReleaseSnapshot则将snapshot从链表中删除。DBImpl类中的snapshots_成员就是这个链表。这部分代码主要在snapshot.h与db_impl.cc/.h中。代码很简单，内部是一个双向循环链表的封装。

const Snapshot* DBImpl::GetSnapshot() {
  MutexLock l(&mutex_);
  return snapshots_.New(versions_->LastSequence());
}

snapshot机制主要会影响指定的读操作与所有后续的压缩操作，直到该snapshot释放。

从前面的使用接口章节中，我们知道，当读操作Get函数指定snapshot选项时，从snapshot生成至Get函数调用的这段时间里的写入操作对该次读没有影响。当指定snapshot时，Get函数会使用这个snapshot的sequencenumber+输入的key来构造要查找的LookupKey（没有指定snapshot，则使用当前已使用的最大sequencenumber）。而对于要查找的数据结构memtable、immunable memtable与sstable来讲，其内部存储的”key”都是带sequencenumber的（上一章节的分析），其最终查找到的”key”会满足key == 输入的key，而sequencenumber<=Get函数传入的sequencenumber。这样，对于那些key相同但sequencenumber比较大（也就是后续针对同一个key做写入操作）的slice，则查找不到，自动的被屏蔽掉了。关于读操作Get的详细细节，我们在后续章节进行分析。

Status DBImpl::Get(const ReadOptions& options,
                   const Slice& key,
                   std::string* value) {
  Status s;
  MutexLock l(&mutex_);
  SequenceNumber snapshot;
  if (options.snapshot != NULL) {
    snapshot = reinterpret_cast<const SnapshotImpl*>(options.snapshot)->number_;
  } else {
    snapshot = versions_->LastSequence();
  }

  MemTable* mem = mem_;
  MemTable* imm = imm_;
  Version* current = versions_->current();
  mem->Ref();
  if (imm != NULL) imm->Ref();
  current->Ref();
  —
  {
    mutex_.Unlock();
    // mem与imm是带sequence_number以保证不会查到新数据
    // 查找顺序依次是：memtable、immutable memtable、sstable文件
    // First look in the memtable, then in the immutable memtable (if any).
    LookupKey lkey(key, snapshot);
    if (mem->Get(lkey, value, &s)) {
      // Done
    } else if (imm != NULL && imm->Get(lkey, value, &s)) {
      // Done
    } else {
      s = current->Get(options, lkey, value, &stats);
      have_stat_update = true;
    }
    —
  }

leveldb的snapshot机制不会在snapshot生成时直接影响系统，而是通过影响压缩操作来影响。比如redis的快照机制，其生成快照时，相当于dump整个内存中的db。
通过前面的Get分析，我们知道，因为SequenceNumber对查找的影响，使得后续的写是完全透明的。但compact操作会将写入的值与已有的值进行合并。这样，后续写入的值可能会覆盖前面已写过的值或者后续的删除操作删除了该key。实际上，在进行major compact时（minor compact只是将immunable memtable转储至1个level 0的sstable文件），会检查这些(key,value)的sequencenumber。当有相同key的多个操作序列时，正常情况下，只会按操作第一个序列（也就是最新的），后续的直接drop。但snapshot机制，会使得对于这些多个操作序列的除第一个之外的操作，只有sequencenumber比系统中最小的snapshot还小的才丢弃（实际细节比这个还复杂点）。这样，这些操作序列都会被保存下来用于后续的snapshot操作。这部分代码主要在DBImpl::DoCompactionWork函数中，更多细节有待我们讲述压缩机制时再来分析。

Status DBImpl::DoCompactionWork(CompactionState* compact) {
   ---
   if (snapshots_.empty()) {
    compact->smallest_snapshot = versions_->LastSequence();
  } else {
    compact->smallest_snapshot = snapshots_.oldest()->number_;
  }
  ---
  Iterator* input = versions_->MakeInputIterator(compact->compaction);
  input->SeekToFirst();
  Status status;
  ParsedInternalKey ikey;
  std::string current_user_key;
  bool has_current_user_key = false;
  SequenceNumber last_sequence_for_key = kMaxSequenceNumber;
  // 遍历输入
  for (; input->Valid() && !shutting_down_.Acquire_Load(); ) {
    // Prioritize immutable compaction work
    if (has_imm_.NoBarrier_Load() != NULL) {
      ---
    }

    Slice key = input->key();
    if (compact->compaction->ShouldStopBefore(key) &&
        compact->builder != NULL) {
        // 输出新文件
      status = FinishCompactionOutputFile(compact, input);
      if (!status.ok()) {
        break;
      }
    }

    // Handle key/value, add to state, etc.
    bool drop = false;
    // 因为有delete、多次插入，同一个key可能出现多次
    if (!ParseInternalKey(key, &ikey)) {
      // Do not hide error keys
      current_user_key.clear();
      has_current_user_key = false;
      last_sequence_for_key = kMaxSequenceNumber;
    } else {
      if (!has_current_user_key ||
         // 注意这里的比较是直接比较user_key，也就是不带sequencenumber
          user_comparator()->Compare(ikey.user_key,
                                     Slice(current_user_key)) != 0) {
        // First occurrence of this user key
        current_user_key.assign(ikey.user_key.data(), ikey.user_key.size());
        has_current_user_key = true;
        last_sequence_for_key = kMaxSequenceNumber;
      }

      if (last_sequence_for_key <= compact->smallest_snapshot) {
        // Hidden by an newer entry for same user key
        // 多个key，后续的是更老的，直接drop，保留第一个
        drop = true;    // (A)
      } else if (ikey.type == kTypeDeletion &&
                 ikey.sequence <= compact->smallest_snapshot &&
                 compact->compaction->IsBaseLevelForKey(ikey.user_key)) {
        // For this user key:
        // (1) there is no data in higher levels
        // (2) data in lower levels will have larger sequence numbers
        // (3) data in layers that are being compacted here and have
        //     smaller sequence numbers will be dropped in the next
        //     few iterations of this loop (by rule (A) above).
        // Therefore this deletion marker is obsolete and can be dropped.
        drop = true;
      }

      last_sequence_for_key = ikey.sequence;
    }
    ---

由于snapshot对压缩机制有影响，对snapshot后续插入的多个值都不会压缩。因此在使用时，用完后要尽可能快释放。

leveldb lookup key

static uint64_t PackSequenceAndType(uint64_t seq, ValueType t) {
  assert(seq <= kMaxSequenceNumber);
  assert(t <= kValueTypeForSeek);
  return (seq <<  \8) | t;
}

skiplist中的单个节点不仅存储了Key，也存储了value。格式如下图。尽管单个节点的开头部分是一个LookupKey，但其内部比较时，还是使用的InternalKey。也就是说，比较时，先使用InternalKey内部的user_key进行比较，再比较sequence_num。这样不管是memtable还是sstable文件，其内部都是按InternalKey有序的。

leveldb skiplist node

int InternalKeyComparator::Compare(const Slice& akey, const Slice& bkey) const {
  // Order by:
  //    increasing user key (according to user-supplied comparator)
  //    decreasing sequence number
  //    decreasing type (though sequence# should be enough to disambiguate)
  int r = user_comparator_->Compare(ExtractUserKey(akey), ExtractUserKey(bkey));
  if (r == 0) {
    const uint64_t anum = DecodeFixed64(akey.data() + akey.size() - 8);
    const uint64_t bnum = DecodeFixed64(bkey.data() + bkey.size() - 8);
    if (anum > bnum) {
      r = -1;
    } else if (anum < bnum) {
      r = +1;
    }
  }
  return r;
}

在进行Get操作时，leveldb会使用用户传入的user_key与当前db最大的sequence_num进行合并，以得到LookupKey（实际还会受snapshot机制影响）。但在内部查找时还是使用的InternalKey。

Put操作会稍微复杂点。leveldb的3种写入操作最终都会封装成WriteBatch。这3种写入操作分别是Put(写入单条key
/value)、Delete(删除单条key)、Write(批量进行Put与Delete操作)。WriteBath的内部格式如下图。WriteBatch所表示的多条记录最终会按SkipList所要求的格式1条条地顺序插入到memtable中。

leveldb writebatch

Status WriteBatchInternal::InsertInto(const WriteBatch* b,
                                      MemTable* memtable) {
  MemTableInserter inserter;
  // memtable 的初始sequence为WriteBatchInternal中的seq
  inserter.sequence_ = WriteBatchInternal::Sequence(b);
  inserter.mem_ = memtable;
  return b->Iterate(&inserter);
}

Status WriteBatch::Iterate(Handler* handler) const {
  Slice input(rep_);
  if (input.size() < kHeader) {
    return Status::Corruption("malformed WriteBatch (too small)");
  }
  // kHeader=12 = seq(8字节) + count(4字节)
  input.remove_prefix(kHeader);
  Slice key, value;
  int found = 0;
  while (!input.empty()) {
    found++;
    char tag = input[0];
    // type:1字节
    input.remove_prefix(1);
    switch (tag) {
      case kTypeValue:
        if (GetLengthPrefixedSlice(&input, &key) &&
            GetLengthPrefixedSlice(&input, &value)) {
          handler->Put(key, value);
        } else {
          return Status::Corruption("bad WriteBatch Put");
        }
        break;
      case kTypeDeletion:
        if (GetLengthPrefixedSlice(&input, &key)) {
          handler->Delete(key);
        } else {
          return Status::Corruption("bad WriteBatch Delete");
        }
        break;
      default:
        return Status::Corruption("unknown WriteBatch tag");
    }
  }
  if (found != WriteBatchInternal::Count(this)) {
    return Status::Corruption("WriteBatch has wrong count");
  } else {
    return Status::OK();
  }
}

关于读写压缩等对key/value的具体操作，我们在后续章节进行分析，这里只需要了解大概。

log文件格式也是分块存储的。跟sstable文件不同的是，一方面sstable是有序存储的，因此为了加速读取，有相关索引，而log文件始终是顺序读写的，不需要定位某个key，因而不需要索引信息。另一方面sstable的data block虽大致按4KB分块，但实际上存储的块大小通常会比4KB大，这主要是因为单条record不会跨block。而log文件中的block则严格保证为一样，默认值为32KB。因此，log文件中的record可能会跨块，为了区分record是否结束，不同的block有不同的类型（kFullType/kFirstType/kMiddleType/kLastType）。如果block剩余的空间足以存储新的record，则type取值为kFullType，否则则有可能出现1个FirstType的block（剩余部分block存储record的部分内容）+ 0或者多个kMiddleType的block + 1个kLastType的block。除了type字段之外，record还包括check sum与数据的长度，最后才是具体的数据。校验和针对type+length+data。详细的格式如下图所示。如果剩余block的空间<7（checksum+length+type），则剩余的直接填充0，另起一块存储数据。leveldb严格按照32k为一个单位读写一个block。

leveldb log

代码主要在log_format.h，log_reader.cc/.h，log_writer.cc/.h。前者定义了一些，log::Writer类用于写，比较简单，log::Reader考虑到容错，稍微复杂些。但整体上还是很简单的，给点耐心看吧。

从前面的分析可知，level 0级的sstable文件是由内存中的immunable memtable经过minor compact形成的(也就是直接dump)，而level>0级的文件是由level-1级别的文件经过major compact形成的。关于compact过程，我们在后续章节分析。这里着重于分析单个sstable文件的相关接口，代码在table/目录。

下图是sstable文件的整体结构。整体上，sstable文件分为数据区与索引区，尾部的footer指出了meta index block与data index block的偏移与大小，data index block指出了各data block的偏移与大小，meta index block指出了各meta block的偏移与大小。

先看footer结构。如下图。footer位于sstable文件尾部，占用空间固定为48个字节。其末尾8个字节是一个magic_number。metaindex_handle与index_handle物理上占用了40个字节，但实际上存储可能连32字节都不到。每一个handle的结构BlockHandle如右图，逻辑上分别表示offset+size，在内存中占用16个字节，但存储时由于采用可变长度编码，每个handle的物理存储通常不到8+8字节。因此这里两个handle总共占用不到32个字节，剩余填充0。

leveldb footer + block handle

Status ReadBlock(RandomAccessFile* file,
                 const ReadOptions& options,
                 const BlockHandle& handle,
                 BlockContents* result) {
  result->data = Slice();
  result->cachable = false;
  result->heap_allocated = false;

  // Read the block contents as well as the type/crc footer.
  // See table_builder.cc for the code that built this structure.
  size_t n = static_cast<size_t>(handle.size());
  char* buf = new char[n + kBlockTrailerSize];
  Slice contents;
  Status s = file->Read(handle.offset(), n + kBlockTrailerSize, &contents, buf);
  if (!s.ok()) {
    delete[] buf;
    return s;
  }
  if (contents.size() != n + kBlockTrailerSize) {
    delete[] buf;
    return Status::Corruption("truncated block read");
  }

  // Check the crc of the type and the block contents
  const char* data = contents.data();    // Pointer to where Read put the data
  // crc32校验
  if (options.verify_checksums) {
    const uint32_t crc = crc32c::Unmask(DecodeFixed32(data + n + 1));
	// data + type + crc
    const uint32_t actual = crc32c::Value(data, n + 1);
    if (actual != crc) {
      delete[] buf;
      s = Status::Corruption("block checksum mismatch");
      return s;
    }
  }

  switch (data[n]) {
    case kNoCompression:
      ---
      // Ok
      break;
    // snappy压缩
    case kSnappyCompression: {
      size_t ulength = 0;
      if (!port::Snappy_GetUncompressedLength(data, n, &ulength)) {
        delete[] buf;
        return Status::Corruption("corrupted compressed block contents");
      }
      char* ubuf = new char[ulength];
      if (!port::Snappy_Uncompress(data, n, ubuf)) {
        delete[] buf;
        delete[] ubuf;
        return Status::Corruption("corrupted compressed block contents");
      }
      delete[] buf;
      result->data = Slice(ubuf, ulength);
      result->heap_allocated = true;
      result->cachable = true;
      break;
    }
    default:
      ---
  }
  ---
}

前面通过ReadBlock读取的BlockContent内容一般通过new Block(BlockContent)初始化为具体的Block对象。现在我们看看Block的内部结构，如下图。逻辑上主要分为数据与重启点。重启点也是一个指针，指出了一些特殊的位置。data block中的key是有序存储的，相邻的key之间可能有重复，因此存储时采用前缀压缩，后一个key只存储与前一个key不同的部分。那些重启点指出的位置就表示该key不按前缀压缩，而是完整存储该key。除了减少压缩空间之外，重启点的第二个作用就是加速读取。如果说data index block可以通过二分来定位具体的block，那么重启点则可以通过二分的方法来定位具体的重启点位置，进一步减少了需要读取的数据。对于leveldb来讲，可以通过options.block_size与options.block_restart_interval来设置block的大小与重启点的间隔。默认data block的大小为4K。而重启点则每隔16个key。具体的单条record的存储格式如下图所示。

leveldb block

leveldb单条记录存储格式

不同block的(key,value)对

leveldb Block::Iter

leveldb BlockBuilder

leveldb filter block

外部使用时，主要有两类接口。一类是读，另一类是写。读接口在table.cc/.h中实现，写接口在table_builder.cc/.h中实现。读接口的调用顺序为，Open打开一个sst文件，然后NewIterator返回一个迭代器用于遍历整个table，或者调用InternalGet用于Seek某个key。这些接口一般通过table_cache类来调用。table_cache是table的缓存。table_cache会先查看是否有cache，没有则读table文件，写cache。table_cache的具体细节我们在Get章节中分析。写接口的调用顺序为，TableBuilder构造函数初始化–>多次调用Add(key,value)–>Finish/Abandon(异常退出)结束。InternalGet的主要代码如下。内部会先查询filter与BlockCache。

Status Table::InternalGet(const ReadOptions& options, const Slice& k,
                          void* arg,
                          void (*saver)(void*, const Slice&, const Slice&)) {
  Status s;
  Iterator* iiter = rep_->index_block->NewIterator(rep_->options.comparator);
  //先定位该值的offset
  iiter->Seek(k);
  if (iiter->Valid()) {
    Slice handle_value = iiter->value();
    FilterBlockReader* filter = rep_->filter;
    BlockHandle handle;
	// 根据该offset查询filter
    if (filter != NULL &&
        handle.DecodeFrom(&handle_value).ok() &&
        !filter->KeyMayMatch(handle.offset(), k)) {
      // Not found
    } else {
      Slice handle = iiter->value();
      // 没被过滤，表示该key可能存在，需要读取对应的block
      Iterator* block_iter = BlockReader(this, options, iiter->value());
      block_iter->Seek(k);
      if (block_iter->Valid()) {
        (*saver)(arg, block_iter->key(), block_iter->value());
      }
      s = block_iter->status();
      delete block_iter;
    }
  }
  ---
}

Iterator* Table::BlockReader(void* arg,
                             const ReadOptions& options,
                             const Slice& index_value) {
  Table* table = reinterpret_cast<Table*>(arg);
  Cache* block_cache = table->rep_->options.block_cache;
  Block* block = NULL;
  Cache::Handle* cache_handle = NULL;

  BlockHandle handle;
  Slice input = index_value;
  Status s = handle.DecodeFrom(&input);
  // We intentionally allow extra stuff in index_value so that we
  // can add more features in the future.

  // block:先查block cache
  // cache的key是table的cache_id + block_offset
  // 每个table文件对应一个唯一的cache_id
  if (s.ok()) {
    BlockContents contents;
    if (block_cache != NULL) {
      char cache_key_buffer[16];

      EncodeFixed64(cache_key_buffer, table->rep_->cache_id);
      EncodeFixed64(cache_key_buffer+8, handle.offset());
      Slice key(cache_key_buffer, sizeof(cache_key_buffer));
      cache_handle = block_cache->Lookup(key);
      if (cache_handle != NULL) {
        block = reinterpret_cast<Block*>(block_cache->Value(cache_handle));
      } else {
        // 没有则直接读取，并加入block cache
        s = ReadBlock(table->rep_->file, options, handle, &contents);
        if (s.ok()) {
          block = new Block(contents);
          if (contents.cachable && options.fill_cache) {
            cache_handle = block_cache->Insert(
                key, block, block->size(), &DeleteCachedBlock);
          }
        }
      }
    } else {
      s = ReadBlock(table->rep_->file, options, handle, &contents);
      if (s.ok()) {
        block = new Block(contents);
      }
    }
  }
  ---
}

写table的主要函数Add与Finish代码如下。代码清晰，请自行阅读。

void TableBuilder::Add(const Slice& key, const Slice& value) {
  Rep* r = rep_;
  assert(!r->closed);
  if (!ok()) return;
  // 需要有序插入
  if (r->num_entries > 0) {
    assert(r->options.comparator->Compare(key, Slice(r->last_key)) > 0);
  }

  // 前面提到过data index block的key，其值需要等候后一个block的key写入时才能构造，pending_index_entry就表示了前一个block的index，此时构造其key，并写入index_block
  if (r->pending_index_entry) {
    assert(r->data_block.empty());
    r->options.comparator->FindShortestSeparator(&r->last_key, key);
    std::string handle_encoding;
    r->pending_handle.EncodeTo(&handle_encoding);
    r->index_block.Add(r->last_key, Slice(handle_encoding));
    r->pending_index_entry = false;
  }

  // 往filter block中添加key
  if (r->filter_block != NULL) {
    r->filter_block->AddKey(key);
  }

  r->last_key.assign(key.data(), key.size());
  r->num_entries++;
  r->data_block.Add(key, value);

  const size_t estimated_block_size = r->data_block.CurrentSizeEstimate();
  // block_size限制
  if (estimated_block_size >= r->options.block_size) {
    Flush();
  }
}

Status TableBuilder::Finish() {
  Rep* r = rep_;
  Flush();
  assert(!r->closed);
  r->closed = true;

  BlockHandle filter_block_handle, metaindex_block_handle, index_block_handle;

  // Write filter block
  if (ok() && r->filter_block != NULL) {
    WriteRawBlock(r->filter_block->Finish(), kNoCompression,
                  &filter_block_handle);
  }

  // Write metaindex block
  if (ok()) {
    BlockBuilder meta_index_block(&r->options);
    if (r->filter_block != NULL) {
      // Add mapping from "filter.Name" to location of filter data
      std::string key = "filter.";
      key.append(r->options.filter_policy->Name());
      std::string handle_encoding;
      filter_block_handle.EncodeTo(&handle_encoding);
      meta_index_block.Add(key, handle_encoding);
    }

    // TODO(postrelease): Add stats and other meta blocks
    WriteBlock(&meta_index_block, &metaindex_block_handle);
  }

  // Write index block
  if (ok()) {
    if (r->pending_index_entry) {
      r->options.comparator->FindShortSuccessor(&r->last_key);
      std::string handle_encoding;
      r->pending_handle.EncodeTo(&handle_encoding);
      r->index_block.Add(r->last_key, Slice(handle_encoding));
      r->pending_index_entry = false;
    }
    WriteBlock(&r->index_block, &index_block_handle);
  }

  // Write footer
  if (ok()) {
    Footer footer;
    footer.set_metaindex_handle(metaindex_block_handle);
    footer.set_index_handle(index_block_handle);
    std::string footer_encoding;
    footer.EncodeTo(&footer_encoding);
    r->status = r->file->Append(footer_encoding);
    if (r->status.ok()) {
      r->offset += footer_encoding.size();
    }
  }
  return r->status;
}

另外还有two_level_iterator.cc/.h与merger.cc/.h类。前者用于构造table上的迭代器，后者用于多个迭代器的归并。

---
# detect what platform we're building on
$(shell CC=$(CC) CXX=$(CXX) TARGET_OS=$(TARGET_OS) \
    ./build_detect_platform build_config.mk ./)
# this file is generated by the previous line to set build flags and sources
include build_config.mk

CFLAGS += -I. -I./include $(PLATFORM_CCFLAGS) $(OPT)
CXXFLAGS += -I. -I./include $(PLATFORM_CXXFLAGS) $(OPT)

LDFLAGS += $(PLATFORM_LDFLAGS)
LIBS += $(PLATFORM_LIBS)
---

build_detect_platform脚本内部使用’uname -s’命令来检测类Unix/Linux操作系统的各版本并设置合适的变量(如CC/PLATFORM等变量，以及选择合适的底层平台文件，主要是port/port_posix.cc)，然后会依次检测编译环境中是否支持c++ 0x、snappy、tcmalloc，比如检测snappy是否安装的代码如下，对于snappy，若已安装，则会定义-DSNAPPY宏：

    # Test whether Snappy library is installed
    # http://code.google.com/p/snappy/
    $CXX $CXXFLAGS -x c++ - -o /dev/null 2>/dev/null  <<EOF
      #include <snappy.h>
      int main() {}
EOF
    if [ "$?" = 0 ]; then
        COMMON_FLAGS="$COMMON_FLAGS -DSNAPPY"
        PLATFORM_LIBS="$PLATFORM_LIBS -lsnappy"
    fi

如果你想更进一步，连leveldb本身提供的Makefile都不想使用，你想将源代码集成进来，则只需要注意包含port/port_posix.cc文件或者其他合适的跨平台文件，以及定义合适的平台参数，比如对于POSIX环境，可简单的使用’-DLEVELDB_PLATFORM_POSIX’就可以编译。

这里简单介绍了leveldb的编译过程，下面来看看其对平台的具体支持。

leveldb大致通过3层来实现平台语义的支持。
第一层是对外接口，在env.cc/.h与mutexlock.h中实现，mutexlock.h提供了锁的上层接口，而env则主要提供了文件与线程操作的上层接口。这部分代码对于不同平台没有多大差别。主要定义了一个抽象接口。
第二层是文件与线程操作的实际实现，对于posix，则为env_posix.cc。
第三层则是一些原子操作的封装，比如信号、锁等。对于posix，对应的文件为port_posix.cc/.h。

第一层：
Env：环境对象，提供文件、目录、线程等的操作接口。用户可自定义新Env对象，以加强对系统的控制；否则会使用默认的Env对象。对于posix，就是PosixEnv对象。
SequentialFile：顺序读文件
RandomAccessFile：随机读文件
WritableFile：顺序写文件
FileLock：文件锁

第二层：
PosixSequentialFile是对SequentialFile接口的实现，也就是简单调用fread读文件。
posix的RandomAccessFile实现有两个，一个是PosixRandomAccessFile，另一个是PosixMmapReadableFile，前者调用pread读取指定偏移的文件数据，后者为使用mmap来读取文件。
PosixMmapFile是对WritableFile接口的实现，始终使用mmap来写文件。

最终的PosixEnv对象通过调用这些子类来对外提供服务。对于随机读文件，在64位环境下，最多允许1000个文件使用mmap的方式，其他则使用pread方式。

第三层：
利用C++的语言特性定义了Mutex、CondVar，以在使用过程中自动释放pthread_mutex_t、pthread_cond_t资源。另外，也提供了Snappy的操作接口：Snappy_Compress与Snappy_Uncompress。

大部分代码并不复杂，这里就不一一分析了。

helpers/memenv目录下实现了自定义的Env类 — InMemoryEnv，完全基于内存操作的Env对象，对自定义Env对象感兴趣的可了解下。

1 内存管理(arena.cc/.h)
leveldb的大部分内存管理依赖于C++语言的默认实现，也就是不对内存进行管理。只是在memtable的实现中用到了一个简单的内存管理器(arena)。因为memtable的内部实现skip list写入时，需要分配新节点，大量节点的直接分配可能会带来较多的碎片，影响运行效率。因此，leveldb在每个memtable中都会绑定一个arena，在memtable进行minor compact后，memtable销毁时进行统一释放。
下图是一个arena某个运行时刻的截图。从图中可以看出，arena内部使用的基本块大小为4K，已分配的块的指保存在一个vector中。具体分配策略如下。若分配的内存可从剩余的块中分配，则直接从剩余块中分配并调整剩余块指针的位置。否则检查要分配的size是否大于1/4的block(也就是1K)，若大于则直接new所需大小的内存，将指针保存在vector中并返回内存指针。从这里可以看出，vector保存的内存块的指针大小可能>4K，也就是对大内存块直接分配。前面两个条件若都不满足，则需要new一个基本块(=4K)，将new出来的新块作为当前块，从这块当中分配内存并调整当前内存指针位置。原来当前块的剩余内存就被浪费掉了。
实际中可考虑用tcmalloc/jemalloc以提升内存管理效率。

leveldb arena

  // alloc_ptr_指向基本块空闲内存位置，alloc_bytes_remaining_为剩余内存大小
  // blocks_保存了所有的块，包括了基本块与直接分配的大块
  // Allocation state
  char* alloc_ptr_;
  size_t alloc_bytes_remaining_;

  // Array of new[] allocated memory blocks
  std::vector<char*> blocks_;

  // Bytes of memory in blocks allocated so far
  size_t blocks_memory_;

2 过滤器bloom filter的实现(bloom.cc)
leveldb通过接口NewBloomFilterPolicy提供了一个filter的实现，使用时通过传入该filter可提升对不存在的数查找时的效率。open db时的options.filter_policy参数指定该filter。如果指定了filter，leveldb会在生成新sst文件时对该文件的所有key构造一个合适的bloom filter字符串并保存在sst文件中。现在我们来看看这个bloom filter的实现机制。bloom filter需要指定bits_per_key参数，表示每个key需要检测多少个bit位/保存多少个bit位。创建bloom filter的核心代码如下：

  virtual void CreateFilter(const Slice* keys, int n, std::string* dst) const {
    // Compute bloom filter size (in both bits and bytes)
    size_t bits = n * bits_per_key_;

    // For small n, we can see a very high false positive rate.  Fix it
    // by enforcing a minimum bloom filter length.
    if (bits < 64) bits = 64;

    size_t bytes = (bits + 7) / 8;
    bits = bytes * 8;

    const size_t init_size = dst->size();
    dst->resize(init_size + bytes, 0);
	// 将探测需要的尾数放至最后
    dst->push_back(static_cast<char>(k_));  // Remember # of probes in filter
    char* array = &(*dst)[init_size];
    for (size_t i = 0; i < n; i++) {
      // Use double-hashing to generate a sequence of hash values.
      // See analysis in [Kirsch,Mitzenmacher 2006].
      uint32_t h = BloomHash(keys[i]);
      const uint32_t delta = (h >> 17) | (h << 15);  // Rotate right 17 bits
      for (size_t j = 0; j < k_; j++) {
        const uint32_t bitpos = h % bits;
        array[bitpos/8] |= (1 << (bitpos % 8));
        h += delta;
      }
    }

创建时，先预留bloom filter所需空间(n * bits_per_key_/8对齐后)，并将需要检测的位数保存至字符串末尾，以方便使用时解出。然后遍历key，计算其hash值，将hash值所对应的bit位置1(需要设置bits_per_key_次，并且后续的bit位从原始的hash值右移17位得到)。过滤函数KeyMayMatch基本就是上述过程的逆过程。bloom filter字符串的内部结构可如下图所示。

leveldb bloomfilter结构

3 默认的cache机制—LRU实现(cache.cc/.h)
leveldb的cache主要是为了加快get操作的性能。cache分为block cache与table cache。table cache针对sst文件，key是file_number，cache的大小为options.max_open_files – 10，在db初始化时创建，且cache机制使用默认的LRU算法，外部没法更改。

  // Reserve ten files or so for other uses and give the rest to TableCache.
  const int table_cache_size = options.max_open_files - 10;
  table_cache_ = new TableCache(dbname_, &options_, table_cache_size);

而block_cache则可以在open时通过options.block_cache参数指定cache实例。外部可自定义合适的cache机制替换系统自带的LRU cache。如果外部没有提供block_cache参数，则leveldb会在初始化时构造8MB大小的cache，该cache同样是LRU cache的实例。该cache的key是block所属table文件的一个cache_id + block在文件中的偏移。

  // 没有提供block_cache，则内部使用8MB的LRUCache
  if (result.block_cache == NULL) {
    result.block_cache = NewLRUCache(8 << 20);
  }

      char cache_key_buffer[16];
      EncodeFixed64(cache_key_buffer, table->rep_->cache_id);
      EncodeFixed64(cache_key_buffer+8, handle.offset());
      Slice key(cache_key_buffer, sizeof(cache_key_buffer));
      cache_handle = block_cache->Lookup(key);

如果用户想自定义block_cache算法，则可参考cache.h中Cache类所定义的抽象接口，主要接口代码如下所示。可以看出，也就是key的增删查改以及句柄的释放。

  // When the inserted entry is no longer needed, the key and
  // value will be passed to "deleter".
  virtual Handle* Insert(const Slice& key, void* value, size_t charge,
                         void (*deleter)(const Slice& key, void* value)) = 0;

  // If the cache has no mapping for "key", returns NULL.
  //
  // Else return a handle that corresponds to the mapping.  The caller
  // must call this->Release(handle) when the returned mapping is no
  // longer needed.
  virtual Handle* Lookup(const Slice& key) = 0;

  // Release a mapping returned by a previous Lookup().
  // REQUIRES: handle must not have been released yet.
  // REQUIRES: handle must have been returned by a method on *this.
  virtual void Release(Handle* handle) = 0;

  // Return the value encapsulated in a handle returned by a
  // successful Lookup().
  // REQUIRES: handle must not have been released yet.
  // REQUIRES: handle must have been returned by a method on *this.
  virtual void* Value(Handle* handle) = 0;

  // If the cache contains entry for key, erase it.  Note that the
  // underlying entry will be kept around until all existing handles
  // to it have been released.
  virtual void Erase(const Slice& key) = 0;

  // Return a new numeric id.  May be used by multiple clients who are
  // sharing the same cache to partition the key space.  Typically the
  // client will allocate a new id at startup and prepend the id to
  // its cache keys.
  virtual uint64_t NewId() = 0;

NewLRUCache函数可调用自带的LRU实现。现在我们来看看LRU的具体实现。下图是LRUCache的内部实现图与相关代码。

单个LRUCache

struct LRUHandle {
  void* value;
  void (*deleter)(const Slice&, void* value);
  LRUHandle* next_hash; // hash链表指针
  LRUHandle* next;       // 循环链表指针
  LRUHandle* prev;
  size_t charge;      // TODO(opt): Only allow uint32_t?
  size_t key_length;
  uint32_t refs;
  uint32_t hash;      // Hash of key(); used for fast sharding and comparisons
  char key_data[1];   // Beginning of key
--
};
class HandleTable {
  ---
  uint32_t length_;
  uint32_t elems_;
  LRUHandle** list_;
  ---
};

class LRUCache {
  ---
  // Initialized before use.
  size_t capacity_;
  ---
  // Dummy head of LRU list.
  // lru.prev is newest entry, lru.next is oldest entry.
  LRUHandle lru_;
  HandleTable table_;
};

static const int kNumShardBits = 4;
static const int kNumShards = 1 << kNumShardBits;
class ShardedLRUCache : public Cache {
  ---
  LRUCache shard_[kNumShards];
  --
};

每个节点有3个指针，一个指针用于hash table的单链接指向。另外两个形成双向循环链表，以实现lru功能，方便控制cache的大小。插入时除了在hash table中查找合适的位置并插入，还需要插入到循环链表的开头。如果数据过多，就通过head来删除最老的节点。对于table，插入的元素个数大于桶的数目时，需要重新调整大小，新的size将是2的幂，但比元素个数多。
leveldb为了加快查找速度，并不只是使用了1个如上所示的LRUCache，而是16个(也就是说会按key再分一次桶)，最终调用的是ShardedLRUCache接口。

4 内部编码/解析器(coding.cc/.h)
leveldb为了节省空间，可对int进行可变长度编码，也就是对小于2^7使用1个字节存储，小于2^14使用两个字节。。。。编码时将输入每隔7位分组，将字节的最高位始终置1，一直到最后1个字节的最高位置0表示结束。比如对int型的二进制数00000000,00000001,11011001,01000110，每隔7位分组则为111,0110010,1000110，再将每个字节的高位置1，则实际存储的为00000111,10110010,11000110。这样比起始终用4个字节存储，省了1个字节的存储空间。实际的编码代码如下：

char* EncodeVarint32(char* dst, uint32_t v) {
  // Operate on characters as unsigneds
  unsigned char* ptr = reinterpret_cast<unsigned char*>(dst);
  static const int B = 128;
  if (v < (1<<7)) {
    *(ptr++) = v;
  } else if (v < (1<<14)) {
    *(ptr++) = v | B;
    *(ptr++) = v>>7;
  } else if (v < (1<<21)) {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = v>>14;
  } else if (v < (1<<28)) {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = (v>>14) | B;
    *(ptr++) = v>>21;
  } else {
    *(ptr++) = v | B;
    *(ptr++) = (v>>7) | B;
    *(ptr++) = (v>>14) | B;
    *(ptr++) = (v>>21) | B;
    *(ptr++) = v>>28;
  }
  return reinterpret_cast<char*>(ptr);

5 默认比较器的实现—字节级比较器
由于leveldb内部是有序的，因此其比较器是至关重要的。头文件中的Comparator类提供了比较器的抽象接口。Name定义了该比较器的名字，会在open时进行检查。至于FindShortestSeparator、FindShortSuccessor表示什么意思，可参看默认的字节级比较器BytewiseComparator的实现，相当简单。

  // Three-way comparison.  Returns value:
  //   < 0 iff "a" < "b",
  //   == 0 iff "a" == "b",
  //   > 0 iff "a" > "b"
  virtual int Compare(const Slice& a, const Slice& b) const = 0;

  // The name of the comparator.  Used to check for comparator
  // mismatches (i.e., a DB created with one comparator is
  // accessed using a different comparator.
  //
  // The client of this package should switch to a new name whenever
  // the comparator implementation changes in a way that will cause
  // the relative ordering of any two keys to change.
  //
  // Names starting with "leveldb." are reserved and should not be used
  // by any clients of this package.
  virtual const char* Name() const = 0;

  // Advanced functions: these are used to reduce the space requirements
  // for internal data structures like index blocks.

  // If *start < limit, changes *start to a short string in [start,limit).
  // Simple comparator implementations may return with *start unchanged,
  // i.e., an implementation of this method that does nothing is correct.
  virtual void FindShortestSeparator(
      std::string* start,
      const Slice& limit) const = 0;

  // Changes *key to a short string >= *key.
  // Simple comparator implementations may return with *key unchanged,
  // i.e., an implementation of this method that does nothing is correct.
  virtual void FindShortSuccessor(std::string* key) const = 0;

未完待续

6 crc32

7 hash

8 histogram

9 logging.cc

10 random.h

整体架构如下图所示：

leveldb整体结构

为了支持kv型的读写删除操作，leveldb在内存与磁盘中分别用了一些数据结构/数据文件。从上图可以看出，内存中主要有memtable与immutable memtable，而磁盘上主要有CURRENT、MANIFEST、.log、LOCK、LOG以及分级的.sst等文件。

内存中的memtable与immutable table本质上都是一个skip list，保存当前写入内存而未持久化至磁盘的数据。对于特定的db来讲，一开始只有一个memtable，当memtable写入操作超过阈值(或者对应的.log文件超过阈值时)后，会转化为immutable memtable。同时会产生新的memtable以供后续数据插入。而immutable memtable是只能读不能写的。

磁盘上的LOCK文件锁住当前db。LOG文件是leveldb运行过程中产生的一些日志(注意跟.log文件区分)。.log文件则跟memtable配合，保存未持久化的写操作，以防运行过程中程序异常导致数据丢失。sst文件保存了最终的数据。随着压缩的进行，会产生不同level的sst文件。为了描述这些sst文件，比如level0有哪些文件，对应的key-range范围，则有相应的MANIFEST文件。而CURRENT文件则指向描述db最新状态信息的MANIFEST。因为leveldb支持version与snapshot机制，随着leveldb的运行，会不断的增删sst数据文件，原有的描述文件可能仍在使用，而CURRENT指向的MANIFEST则始终表示最新的描述文件。

再来看看leveldb运行过程中的主要操作。
先来看写入操作(put)。从架构图可以看出，leveldb会先将写入操作写至.log文件，写入成功后再写入memtable。由于写log是追加写，而写memtable是skip list的内存操作，因此leveldb的写是相当快的。

对于读操作(get)来讲，主要分为3步。先查memtable，没有找到则在immutable memtable中继续查找；若还没有找到，则表示对应的key-value数据可能已持久化至磁盘中，因此需要借助MANIFEST文件来找到对应的sst文件，然后再在对应的sst文件中查找。由于MANIFEST文件常驻内存，而MANIFEST保存了不同sst文件的key-range，因此查找对应的文件是很快的。找到对应的文件后，由于sst文件内部是有序的，并且有相应的索引索引不同key-range的value，因此需要先读入这些索引，再在索引中二分查找，再根据索引找到对应的块，然后遍历相应的块查找。这个过程可能需要两次大范围的读文件操作。一次是读索引，一次是读对应的block。为了加快这个操作，leveldb有相应的table cache与block cache，以分别加速sst文件与block的读操作。另外有些数据可能在db中就不存在，为了加速这些数据的查找，每个sst文件都可以添加合适的bloom filter。bloom filter是在载入相应的sst文件后对数据进行过滤的。

最后来看看压缩(compact)操作。leveldb的压缩操作分为minor compact与major compact。所有的压缩操作都是启动一个新线程来完成的。从架构图可以看出，minor compact就是遍历immutable memtable(本质上是一个skip list)，dump至一个新的level0 sst文件。从这里可以看出，新dump出来的sst文件可能会跟已有的level0级别的sst文件存在key-range上的重叠。而level[1-6]上的sst文件则不会存在这个这个问题，level[1-6]上的文件是由上一级文件进行major compact得到的。当level 0层文件数超过阈值(>=4)，会触发level0与level1层文件合并。而对于大于等于level1以上的level，总文件字节数超过阈值(10M 100M 1G 10G 100G 1T(level=6))则会触发该操作。至于选择哪个文件与下一级别的文件进行compact，则是轮流进行的。另外如果特定level文件的seek次数(也就是访问次数)超过阈值，也会触发对应的major compact操作，此时则会直接选择该文件与下一level进行major compact操作。

后续我们将先分析内存与磁盘上的数据结构/文件格式代码，再分析GET/PUT等操作对应代码。在此之前，我们看看leveldb源代码的目录结构。
doc/: 包括了一些文档，
> benchmark.html       性能测试文档
> impl.html                   内部实现文档
> index.html                 使用文档
> log_format.html       .log文件格式
> table_format.html   .sst文件格式

helpers/:提供了一个简单的内存文件操作接口，相当于实现了一个Env接口。Env接口对应了leveldb运行的底层平台。
include/leveldb/:对外接口，使用时include该目录下的头文件即可。
> cache.h cache接口，用户可实现合适的cache接口，以加速读操作
> c.h leveldb是用c++编写的，这里提供了c的对外封装
> comparator.h
db.h
env.h
filter_policy.h
iterator.h
options.h
slice.h
status.h
table_builder.h
table.h
write_batch.h

util/:
> arena
> bloom
> cache
> coding
> comparator
> crc32c
> env
> env_posix
> filter_policy
> hash
> histogram
> logging
> mutexlock
> options
> posix_logger
> random
> status
> testharness
> testutil

port/:
> atomic_pointer
> port_example
> port
> port_posix
> README
> thread_annotations

table/: sst table相关操作的封装
> block_builder
> block
> filter_block
> format
> iterator
> iterator_wrapper
> merger
> table_builder
> table
> two_level_iterator

db/:leveldb主要操作的实现部分
> builder
> c
> db_bench
> dbformat
> db_impl
> db_iter
> filename
> log_format
> log_reader
> log_writer
> memtable
> repair
> skiplist
> snapshot
> table_cache
> version_edit
> version_set
> write_batch
> write_batch_internal

0 官方文档
http://leveldb.googlecode.com/svn/trunk/
源代码，主要使用了1.7.0版本
https://leveldb.googlecode.com/files/leveldb-1.7.0.tar.gz

http://leveldb.googlecode.com/svn/trunk/doc/index.html
官方使用手册，比较详细

http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
官方的性能测试

http://leveldb.googlecode.com/svn/trunk/doc/impl.html
比较粗略的介绍了leveldb的主要实现细节

http://leveldb.googlecode.com/svn/trunk/doc/table_format.txt
http://leveldb.googlecode.com/svn/trunk/doc/log_format.txt
sstable文件格式与log文件格式

1 原理
【朗格科技】LevelDb日知录系列 http://www.samecity.com/blog/Index.asp?SortID=12
数据分析与处理之二（Leveldb 实现原理）
http://www.cnblogs.com/haippy/archive/2011/12/04/2276064.html
比较详尽的介绍了leveldb各模块的工作原理与实现细节，缺点是没有源代码细节。对leveldb最初细节的了解，也起于该文。建议读者可先阅读此文，以对leveldb的原理有最初的印象。另外，作者似乎没有把该系列写完。

leveldb实现解析.pdf
从代码细节上进行了分析，不过对于初接触者恐怕容易陷入过多的细节，缺乏整体性的介绍。建议对原理有了大致了解，且初读代码后，再进行对照学习。

2 性能
关于LevelDB http://blog.sina.com.cn/s/blog_593af2a70100ztjn.html

LevelDB 写操作出现停顿的问题分析 http://www.ideawu.net/blog/archives/709.html

Performance data for LevelDB, Berkley DB and BangDB for Random Operations
http://highscalability.com/blog/2012/11/29/performance-data-for-leveldb-berkley-db-and-bangdb-for-rando.html

leveldb与kyoto cabinet性能测试
http://blog.creapptives.com/post/8330476086/leveldb-vs-kyoto-cabinet-my-findings

3 相关实现
go实现 https://code.google.com/p/leveldb-go

Tair ldb(LevelDB)原理与应用案例.pdf

leveldb+redis https://github.com/qiye/redis-storage
ssdb https://github.com/ideawu/ssdb
sophia https://github.com/pmwkaa/sophia