分布式专题——详解Google levelDB底层原理

本文始发于个人公众号：TechFlow，原创不易，求个关注

今天是分布式专题的第10篇文章，我们继续来聊聊LSMT这个数据结构。

LSMT是一个在分布式系统当中应用非常广泛，并且原理直观简单的数据结构。在上一篇文章当中我们进行了详细的讨论，有所遗忘或者是新关注的同学可以点击下方的链接回顾一下上一讲的内容。

分布式——吞吐量巨强、Hbase的承载者 LSMT

leveldb简介

上一篇的内容我们介绍的算是最基础版本的LSMT，在这一篇当中，我们来具体看下levelDB这个经典的KV数据库引擎当中LSMT的使用以及优化。

leveldb，既然是叫做db，显然和数据库有关。和一般的关系型数据库不同，它内部的数据全部以KV也就是key-value形式存储，并且不支持结构化的SQL进行数据查询，只支持api调用。也就是说它就是一个典型的我们常说的noSQL数据引擎库。它最早由google开发并且开源，Facebook在此基础上进行优化，推出了更普及的RocksDB，后来包括TiDB等多种分布式noSQL数据库的底层都是基于leveldb。

如果上面这些名词你都没听说过，也没有关系，对于这些库而言，上手去用容易，但是了解原理难。搞懂了原理再实际上手去用，除了更加简单之外，也会有更多的体会。

leveldb架构

这是一张leveldb的架构图，比之前介绍的裸的LSMT的架构图要复杂一些，但是核心本质是一样的，我们一个一个来看。

首先上层是MemTable，和Immutable MemTable。MemTable我们都知道，其实本质上就是一个存放在内存当中的数据结构。可以是SkipList也可以是红黑树或者是其他的平衡树(在leveldb当中，使用的是SkipList)，我们只需要确定，它是存储在内存当中的。Immutable MemTable其实也是MemTable，前面的Immutable是不可修改的意思。之前我们说过，当MemTable当中的内容超过某个阈值的时候，我们需要将其中的内容写成一个SSTable的文件。这个ImmuTable MemTable就是在这个时候用的。

当一个MemTable在开始执行持久化之前，会先转化成ImmuTable MemTable，可以认为是加上了不可修改的限制。另外，会再新建一个新的MemTable，用于维持服务。之后再将ImmuTable MemTable写入进SSTable文件。

打个比方，MemTable就好像是收银台里的收银柜，当我们一个门店开张，显然需要有收银柜存放顾客付的钱。当收银柜快满的时候，我们需要将里面的钱存入银行。但是里面的钱不少，并且还有顾客在源源不断地付钱，我们让它停一会会带来损失。所以我们把整个收银柜一起拿走，为了安全，我们在外面加上一把锁，锁起来