LevelDB Cache实现机制分析
几天前淘宝量子恒道在博客上分析了HBase的Cache机制，本篇文章，结合LevelDB 1.7.0版本的源码，分析下LevelDB的Cache机制。
- 概述
LevelDB是Google开源的持久化KV单机存储引擎，据称是HBase的鼻祖Bigtable的重要组件tablet的开源实现。针对存储面对的普遍随机IO问题，LevelDB采用merge-dump的方式，将逻辑场景的随机写请求转换成顺序写log和写memtable的操作，由后台线程根据策略将memtable持久化成分层的sstable。针对读请求，LevelDB会首先查找内存中的memtable和imm（不可变的memtable），然后逐层查找sstable。
为了加快查找速度，LevelDB在内存中采用Cache的方式，在sstable中采用bloom filter的方式，尽最大可能减少随机读操作。
LevelDB的Cache分为两种，分别是table cache和block cache。table cache缓存的是sstable的索引数据，类似于文件系统中对inode的缓存；block cache是缓存的block数据，block是sstable文件内组织数据的单位，也是从持久化存储中读取和写入的单位；由于sstable是按照key有序分布的，因此一个block内的数据也是按照key紧邻排布的（有序依照使用者传入的比较函数，默认按照字典序），类似于Linux中的page cache。
block默认大小为4k，由LevelDB调用open函数时传入的options.block_size参数指定；LevelDB的代码中限制的block最小大小为1k，最大大小为4M。对于频繁做scan操作的应用，可适当调大此参数，对大量小value随机读取的应用，也可尝试调小该参数；
block cache默认实现是一个8M大小的LRU cache，为了减少锁开销，该LRU cache还分成了16个shard。此参数由options.block_cache设定，即可改变缓存大小，也可根据自己的应用需求，提供新的缓存策略。注意，此处的大小是未压缩的block大小。针对大块文件的读写遍历等需求，为了避免读入的块把之前的热数据都淘汰掉，可以在ReadOptions里设置哪些读取不需要进cache，如以下代码所示：
leveldb::ReadOptions options;
options.fill_cache = false;
leveldb::Iterator* it = db->NewIterator(options);
for (it->SeekToFirst(); it->Valid(); it->Next()) {
...
}
table cache默认大小是1000，注意此处缓存的是1000个sstable文件的索引信息，而不是1000个字节。table cache的大小由options.max_open_files确定，其最小值为20-10，最大值为50000－10。
- 源码分析
1.默认的Cache是一个分Shard的LRU Cache，代码片段如下：
leveldb-1.7.0/util/cache.cc
136 class LRUCache {
137 public:
138 LRUCache();
139 ~LRUCache();
140
141 // Separate from constructor so caller can easily make an array of LRUCache
142 void SetCapacity(size_t capacity) { capacity_ = capacity; }
143
144 // Like Cache methods, but with an extra "hash" parameter.
145 Cache::Handle* Insert(const Slice& key, uint32_t hash,
146 void* value, size_t charge,
147 void (*deleter)(const Slice& key, void* value));
148 Cache::Handle* Lookup(const Slice& key, uint32_t hash);
149 void Release(Cache::Handle* handle);
150 void Erase(const Slice& key, uint32_t hash);
151
152 private:
153 void LRU_Remove(LRUHandle* e);
154 void LRU_Append(LRUHandle* e);
155 void Unref(LRUHandle* e);
156
157 // Initialized before use.
158 size_t capacity_;
159
160 // mutex_ protects the following state.
161 port::Mutex mutex_;
162 size_t usage_;
163 uint64_t last_id_;
164
165 // Dummy head of LRU list.
166 // lru.prev is newest entry, lru.next is oldest entry.
167 LRUHandle lru_;
168
169 HandleTable table_;
170 };
1) capacity_是Cache大小，其单位可以自行指定（如table cache，一个sstable文件的索引信息是一个单位，而block cache，一个byte是一个单位）；
2）lru_是一个双向链表，如注释说明，lru_.prev是最新被访问的条目，lru_.next是最老被访问的条目。在访问cache中的一个数据时，会顺次执行LRU_Remove和LRU_Append函数，将条目移到lru_.prev的位置；
3）table_是LevelDB自己实现的一个hash_map，其实现也在cache.cc文件中，据作者说，在特定的编译环境下性能更优，如与g++ 4.4.3内置的hashtable相比，随机读性能可以提升5％；
4）insert操作会根据capacity_的大小，顺着lru_.next讲老的条目Release掉；
2. block 的读取逻辑，代码片段如下：
leveldb-1.7.0/table/table.cc
154 Iterator* Table::BlockReader(void* arg,
155 const ReadOptions& options,
156 const Slice& index_value) {
157 Table* table = reinterpret_cast<Table*>(arg);
158 Cache* block_cache = table->rep_->options.block_cache;
159 Block* block = NULL;
160 Cache::Handle* cache_handle = NULL;
161
162 BlockHandle handle;
......
168 if (s.ok()) {
169 BlockContents contents;
170 if (block_cache != NULL) {
......
175 cache_handle = block_cache->Lookup(key);
176 if (cache_handle != NULL) {
177 block = reinterpret_cast<Block*>(block_cache->Value(cache_handle));
178 } else {
179 s = ReadBlock(table->rep_->file, options, handle, &contents);
180 if (s.ok()) {
181 block = new Block(contents);
182 if (contents.cachable && options.fill_cache) {
183 cache_handle = block_cache->Insert(
184 key, block, block->size(), &DeleteCachedBlock);
185 }
186 }
187 }
188 } else {
189 s = ReadBlock(table->rep_->file, options, handle, &contents);
190 if (s.ok()) {
191 block = new Block(contents);
192 }
193 }
194 }
195
196 Iterator* iter;
197 if (block != NULL) {
198 iter = block->NewIterator(table->rep_->options.comparator);
199 if (cache_handle == NULL) {
200 iter->RegisterCleanup(&DeleteBlock, block, NULL);
201 } else {
202 iter->RegisterCleanup(&ReleaseBlock, block_cache, cache_handle);
203 }
204 } else {
205 iter = NewErrorIterator(s);
206 }
207 return iter;
208 }
1) 首先从block cache中查找block，如果找不到，直接从持久化存储中读取，获取到一个新的block，插入block cache;
2) 对于查到的block，返回对应的迭代器（LevelDB中，所有的get\merge操作均是抽象成iterator实现的）；
3）如果仔细读代码，iter->RegisterCleanup函数实现会有点绕，这个函数在iter析构时被调用，执行注册的ReleaseBlock，ReleaseBlock调用cache_handle的Unref方法，对cache中缓存的block减少一个引用计数；cache执行insert函数时，会给所有的LRUHandle的引用计数设成2，其中1用于LRUCache自身，在执行cache的Release操作时被Unref，从而真正释放。
3.table cache的读取逻辑，代码片段如下：
leveldb-1.7.0/db/table_cache.cc
45 Status TableCache::FindTable(uint64_t file_number, uint64_t file_size,
46 Cache::Handle** handle) {
47 Status s;
48 char buf[sizeof(file_number)];
49 EncodeFixed64(buf, file_number);
50 Slice key(buf, sizeof(buf));
51 *handle = cache_->Lookup(key);
52 if (*handle == NULL) {
53 std::string fname = TableFileName(dbname_, file_number);
54 RandomAccessFile* file = NULL;
55 Table* table = NULL;
56 s = env_->NewRandomAccessFile(fname, &file);
57 if (s.ok()) {
58 s = Table::Open(*options_, file, file_size, &table);
59 }
60
61 if (!s.ok()) {
62 assert(table == NULL);
63 delete file;
64 // We do not cache error results so that if the error is transient,
65 // or somebody repairs the file, we recover automatically.
66 } else {
67 TableAndFile* tf = new TableAndFile;
68 tf->file = file;
69 tf->table = table;
70 *handle = cache_->Insert(key, tf, 1, &DeleteEntry);
71 }
72 }
73 return s;
74 }
和block cache类似，首先查找cache，如果找不到，直接从硬盘中读取。注意代码70行Insert函数的第3个参数，1表示每个sstable的索引信息在cache总占用1个单位的capacity_。其他内容不再赘述。
- 总结
LevelDB是Jeff Dean, Sanjay Ghemawat的作品，实在是值得大家仔细品读。Cache机制非常简单，相信大家通过这篇文章能够非常清楚的了解其cache实现，其思路其实和文件系统的cache是一样的。另外，淘宝已经在Tair线上环境中大量使用了LevelDB存储引擎，推荐那岩写的《LevelDB实现解析》，35页的文档，结合着读代码，会对理解代码，有非常大的帮助。
浙公网安备 33010602011771号