深入浅出带你走进 RocksDB

RocksDB 是基于 Google LevelDB 研发的高性能 Key-Value 持久化存储引擎，以库组件形式嵌入程序中，为大规模分布式应用在 SSD 上运行提供优化。RocksDB 重点是提供工具支持，具体实现将交给上层应用。

正是这种高度可定制化能力，使得 RocksDB 可涵盖包括工作负载等众多场景的应用，今天我们将逐一为大家介绍：

“为什么需要内存管理器？
为什么不使用现有的内存管理器？
RocksDB 究竟是如何实现的？”

01 为什么需要内存管理器？

RocksDB 有很多核心场景需要分配内存的，包括但不限于 Memtable、 Cache、Iterator 等，高效优质的内存分配器就显得尤为重要。一个优秀的通用内存分配器需要具备以下特性:

• 尽量避免内存碎片；并发分配性能好；
• 额外的空间损耗尽量少；
• 兼具通用性、兼容性、可移植性且易调试。

内存管理可以分为 3 个层次，自下而上分别是：

• 操作系统内核的内存管理；
• glibc 层使用系统调用维护的内存管理；
• 应用程序从 glibc 层动态分配内存后，根据应用程序本身的程序特性进行优化， 比如使用引用计数、std::shared_ptr、apache 等内存池方式的内存管理。

目前大部分服务端程序使用 glibc 提供的 malloc/free 系列函数，而 glibc 使用的 ptmalloc2 在性能上远远落后于 Google 的 Tcmalloc 和 Facebook 的 Jemalloc 。 后两者只需使用 LD_PRELOAD 环境变量启动程序即可，甚至并不需要重新编译。

02 为什么不使用现有内存管理器？

RocksDB 使用内存的场景集中在 Memtable、Cache、Iterator 等核心链路上，在保证高性能的同时，还需要实现对内存分配器内部控制（包括监控等）。

当前现有的内存分配器不具有主动上报内存监控细节，所以从长远看，依旧需要自己实现 RocksDB 专有的内存管理器。内存管理器设计思路如下：

• 小内存的申请通过 Thread-cache 或者 Per-cpu cache，保证了 CPU 不会频繁的 cache-miss；
• 若支持 MAP_HUGETLB，则会直接 mmap；
• 若大页内存则直接从底层的分配器去申请。

03 RocksDB 是如何实现的？

如图所示，RocksDB 的内存管理器是支持并发的，接下来让我们一起从源码入手，看看具体如何实现的。

Allocator

// Abstract interface for allocating memory in blocks. This memory is freed
// When the allocator object is destroyed. See the Arena class for more info.
class All