LevelDB 的目录结构很简单，就不用介绍了，直接进入正题吧。

leveldb::DB

LevelDB 暴露给外部的操作接口都很简单，具体可以根据上面提供的索引链接看看代码和注释。

读操作

virtual Status Get(const ReadOptions& options, const Slice& key, std::string* value) = 0;

1. 。
2. ：如果 ReadOptions 参数的 snaphot 不为空，则使用这个 snapshot 的 Sequence Number；否则，默认使用 LastSequence（LastSequence 会在每次写操作后更新）。
3. MemTable， Immutable Memtable 和 Current Version ，避免在读取过程中被后台线程进行 Compaction 时“垃圾回收”了。Version 主要用来维护 SST 文件的版本信息。
4. ，下面 5 和 6 两步是没有持有锁的，特别是第 6 步。
5. 。
6. 查找
   1. 。
   2. 。
   3. 。
8. ，根据统计结果决定是否。
9. MemTable, Immutable Memtable 和 Current Version 。
10. 释放锁（由析构函数完成），。

MemTable

上面分析读流程的时候，可以发现第 6 步，从 Memtable、Immutable Memtable 和 Current Version 指向的 SST 文件查找内容是不需要持有锁的。这样做没有并发读写的问题吗？

简单分析一下：引用计数保证了相关文件和内存数据结构不会被回收，而 Immutable Memtable 和 SST 文件都是只读的，没有并发读写问题。所以，只要看 MemTable 是否支持并发读写。

1. 写写冲突需要外部同步。
2. 读写冲突不需要外部同步，只要保证 SkipList 不会被垃圾回收就好。
3. 这里的 SkipList 只插入，不修改和删除 。

因此，从这段注释可以看出，MemTable 支持一写多读同时并发操作。后面有机会聊到 LevelDB 的写操作再来介绍一下 SkipList 的 Insert 操作如何实现读写并发不需要锁。

LookupKey

1. klength 的类型是 varint32，是 leveldb 内部编码的可变长度的 uint32_t，。表示一个 varint32 最多需要 5 个字节。
2. userkey 就是一个 userkey 的 char 数组。
3. tag 是使用 LittleEndian 编码的 uint64，其组成是 7 字节的 sequence 和 1 字节的 value_type。
4. 所以，一个 LookupKey 的最大长度为: 5 + userkey size + 8 = 。

SST 文件的查找

1. 从 level0 开始 —— 小 level 的数据比大 level 新，所以如果先找到了的话可以直接返回。
2. 在要查找的 level 收集需要查找的文件。level0 的 sst 文件比较特殊，是直接由 Immutable MemTable dump 得到的，因此，每个文件的 key 范围可能重叠。level0 可能需要查找多个文件，其它 level 的 文件的 key 不会重叠，至多只需要读一个文件。
3. 对步骤 2 收集到的文件进行。具体查找逻辑由 实现。这里面涉及一些 Cache 相关的实现，暂时略过。
4. 查找过程会：如果不止读取一个 sst 文件，则记录最后读取的是哪个 level 的哪个文件。

读触发的 Compaction

小结

这里只是简单介绍了 LevelDB 的读操作的大概情况。实际上，LevelDB 的读操作涉及很多东西，如：写操作相关的并发读写、Sequence Number 等；Compaction 相关的 Version、VersionSet等；读操作还有可能触发 Compaction；还有 Table Cache、Block Cache 这些相关的东西没提及。

参考文档