引言：前一篇文章已经介绍过，TIDB的核心存储机制为RocksDB，而RocksDB是一个基于日志结构归并树（LSM树）的KV数据存储引擎。那么RocksDB的系统结构究竟如何？他又相较于前辈LevelDB有了何种优化呢？
01
简介
Rocksdb是由facebook基于leveldb开发的，一套基于LSM树结构的数据存储引擎。针对SSD做过相应的特殊化优化处理，能够高速吞吐PB级的数据，又有极高的IO效率。02
框架
与其他的LSM树结构的KV数据库基本一致，RocksDB也分为了内存区和磁盘区两个部分。下图为RocksDB的基本结构图。如图所示，RocksDB的主要部分有：①ColunFamily（CF）：列族，与HBase中的CF类似，由于将相同类的KV对进行分类存储；②Memtable：数据内存表，上层写入的数据将被直接写入到此表；③ImmutableMemtable：不可变的内存表，在Memtable达到预设阈值时自动转变为ImmutableMemtable，开始flush操作；④WAL：Write-AheadLogging，预写日志，用于数据出错恢复；⑤SST：磁盘存储数据模块。03
ColumnFamily
其中CF是RocksDB基于leveldb进行扩充的部分。CF的作用在于将不同类型的数据KV对进行区分开，对数据集进行逻辑上的划分，这能够较好地保证数据独立性。每个CF中可以简单理解为一个LevelDB，每个CF都包含一个MemTable和多个ImmutableMemtable，也有独立的Flush机制，但与LevelDB不同的是，CF之间共享同一个WAL，以保证数据的一致性，避免写不同的WAL出现数据错乱的情况。04
写数据机制
在RocksDB中，与levelDB不同的是，Rocksdb的写流程时可以并行进行。数据在进行写入到数据库中时，首先会构建相应Writer结构，在通过BatchGroup线程完成调度。现有的写机制主要有两种:①一组数据均有作为Leader的Writer写入，即单线程模式，Leader首先写入WAL后，再写入数据到Memtable中；②作为Leader的Writer写完WAL后，通知其他Writer，Writer接到Leader的信号后开始并行完成自己的数据写入到Memtable中。05
管道机制
对于多组数据的写入，正常情况下的写入流程为两个WriteGroup依次写入数据，完成数据写入。RocksDB针对这种情况提供了一种PipelineWrite机制，将写数据的流程转化为流水线的形式，提升写数据效率。正常的写流程分为写WAL和写Memtable。两个写流程串行时，写开销为2*(Twal+Tmem),而如图的流水线形式能够减少第二次的写WAL的开销。实测管道功能的开启能够带来将近20%的性能提升。06
Flush机制
一个LSM树结构的存储系统flush操作和