读写流程
不同于InnoDB， RocksDB使用日志合并树模型(LSM)。往RocksDB中写数据时(启用memtable和WAL)，先写WAL，然后写memtables。memtables写满了，会触发后台任务， 将写满的memtables中的数据flush到磁盘，生成sst文件到第0层， sst文件一旦生成，其内容就不再改变。 同时，对数据库结构的修改，会触发后台任务运行，从上到下（层数从0开始编号， 从小到大），计算每一层中是否有文件需要合并，如有sst文件满足合并条件，这些文件会被合并，生成新的sst文件，放到合适的层中，可能是当前层，也可能是下一层。可以注意到，RocksDB中数据的持久化和数据文件的合并，只涉及到如下文件操作：生成一个新文件，读取若干文件，删除已存在文件，因此只有追加写，没有随机写。RocksDB的写性非常好。
从RocksDB中读取数据，先去memtables中去读，如果memtables中没有，就去第0层中读，如果还未命中，就从第1层起，逐层找。RocksDB维护了每层中key的范围， 且除了第0层，其他每层中任意两个文件的key范围是不重叠的，且任意一个sst文件中key都是有序的。 由于memtables和第0层的数据都位于内存，且通常不大； 而每层中每个文件所包含的key是已知的，所以能很快找到key所在的目标文件， 因此查找操作也能有相当好的性能。另外，需要注意的时，如果在上层中找到目标key，就不需要到更下面的层中去找了。
Manifest文件
从上面的读写流程我们知道，为了快速从RocksDB中读取某个key的数据，或者快速定位哪些文件需要合并，需要维护一些常驻内存的信息， 也就是整个LSM树的结构， 以加速查找和合并；同时，LSM的结构，在数据库重启时，需要能够快速重建，因此需要把这些信息持久化，Manifest文件就是这些信息的持久化存在。 RocksDB官方文档里，对Manifest文件的描述是: Manifest是一个记录了数据库状态变化的事务性日志。关注两点，一是事务性日志，二是记录了数据库状态的变化，也就是说，Manifest文件的记录着改变数据库状态的操作。从Ref 2中可以知道，Manifest文件中记录了诸如新增sst文件到某一层，当前日志文件名，之前日志文件名，当前Manifest文件名等操作。 每一个操作都将数据库置为一个新的状态，也就是一个新的版本。Manifest文件的更新在VersionSet::LogAndApply中实现，可以通过定位这个方法的调用点查看在哪些情况下Manifest文件被更新了。 Manifest文件作为一个事务性日志文件，只要数据库有变化，其状态就会增长，因此Manifest达到一定大小会被VersionSet::WriteSnapshot重写。
现在，我们回到之前的问题，在进程Crash后如何恢复数据库。简言之，就是两个恢复，第一步，读取Manifest文件，在内存中重建LSM树的结构； 第二步，恢复WAL日志文件。 因为在进程Crash时，memtables中的数据可能并没有刷盘，因此需要从WAL中恢复。
版本号和快照
我们知道，Manifest文件的任一时刻的状态，都代表着RocksDB的一个状态，这是一个比较宏观的状态。 我们知道Manifest的每一次更新都意味着RocksDB进入一个新的状态，但是进入了哪一个状态，我们是不知道的。 而事实上，对RocksDB的每一次写操作，都会形成一个版本，这个版本号为一个8字节的整数，作为key的一部分写入到数据库中去， 具体而言是追加到key后面； 由于RocksDB中所有的key是有序的，因此同一个key的所有版本都会聚集在一起。 有了精确到每个写操作的版本号，很多事情都好办了，最直接的就是快照的实现。 例如，要获取RocksDB某个版本的数据，只需要获取并保存当前数据库的全局版本号，并将其标记为快照即可，后续所有的覆盖写，删除，和合并操作时，都会维持每个快照数据的一致性。
物理备份
RocksDB使用数据文件(sst 文件) + 日志文件， 来记录数据，同时使用Manifest文件记录LSM树的结构信息。基于这些条件，RocksDB可以提供point-of-time的数据备份功能, 具体API可参考官方文档。 实现原理原理如下：
- 禁止RocksDB删除文件 (sst文件和日志文件)
- 获取所有在RocksDB中被使用的文件(sst文件， CURRENT文件，配置文件，以及Manifest文件)
- 将所有的文件拷贝到指定的备份目录
- 允许RocksDB删除文件
我们知道， sst文件一旦生成就不会改变，只可能在合并时被删除，因此一旦禁止了文件的删除，在使用Manifest文件重建LSM结构时，所有需要的sst文件和WAL文件都会存在， (当然，有些文件可能不需要）。恢复了LSM结构信息后，通过恢复WAL，可以获取在做备份时的memtables内容。 这里，需要注意的是，本质上，RocksDB备份是文件拷贝，耗时长短取决于文件的数量和大小；而在文件拷贝的过程中，写入不会被阻塞，因此WAL的内容在备份过程中会发生改变。RocksDB提供了一个选项，flush_before_backup来控制是否也要拷贝WAL, 如果flush_before_backup被设置为true，备份期间不拷贝WAL文件，因为memtables中的数据已经被耍到了sst中。 这个选项对于控制备份的状态很有用， 例如，对于测试备份恢复的正确性，很有帮助， 因为测试者可以精确记录在调用backup之前做了哪些写操作，同时在backup的过程中，继续写入数据。
小结
RocksDB是LevelDB的变种，是一个基于LSM的key/value的存储引擎，具有很多优秀的特性， 已经在业界有了广泛的使用，如开源的tidb和cockroachdb， 脸书的MyRocks，以及头条，陌陌等公司的一些优秀实践，值得关注。本文简单介绍了一些基本原理。RocksDB本身的实现还是比较复杂的， 使用方式也非常灵活， 限于篇幅，这里不过于深入细节。 欢迎讨论。