（一）背景三年前，我用 Fiber(协程) 实现了 TerarkDB 中 MultiGet 的 IO 并发，因为 TerarkDB 分叉自 RocksDB 5.18，其 MultiGet 实现简单直接，所以我可以用 10 行代码就对其完成 Fiber(协程) 改造，并获得数量级的性能提升。但是在 ToplingDB 中，为了充分借助社区力量，吸收社区成果，我们总是在 RocksDB 的最新版上展开工作，基本上每一两个月就会合并一次 RocksDB 上游代码。然而最近两三年，上游 RocksDB 对 MultiGet 进行了大规模的修改：针对每个 SST 的 MultiRead，在 FSRandomReadFile 中增加了 MultiRead 接口因为 MultiGet 中多个 Key 落到同一个 SST 的概率太低，从而对单个 SST 的 MultiRead 收益太小所以 RocksDB 又在 FSRandomReadFile 中增加了 ReadAsync 接口MultiGet 的整个执行链路都进行了相应修改以支持 MultiRead 和 ReadAsync其中用到了 folly::Coroutine和 C++20 的 Coroutine默认情况下 Coroutine 选项是关闭的(控制宏USE_COROUTINES)Coroutine 选项打开时，同时会打开 USE_FOLLY通过另一个宏 WITH_COROUTINES 来生成整个调用链路上的所有相关函数的异步版：TableCache::MultiGet 的异步版 MultiGetAsyncVersion::MultiGetFromSST 的异步版 MultiGetFromSSTAsyncTableCache::MultiGet 的异步版 MultiGetAsyncBlockBasedTable::RetrieveMultipleBlocks 的异步版 RetrieveMultipleBlocksAsync在调用实际干活的 MultiGet 之前，还需要复杂的 Prepare 操作构造专门的 MultiGetContext 对象，调用链上的函数都增加 MultiGetContext::Range 参数MultiGet 增加了额外的参数 is_sorted，表示要 MultiGet 的多个 Key 是否已经排序，如果未排序，就要先进行排序就连不需要 IO 的 MemTable 也增加了 MultiGet 接口所有这些下来，相关的代码修改数以万行计，并且因为不必要的计算太多，对性能有较大影响，在 Cache 命中的情况下（不需要 IO），反而对性能有很大的负面影响。BTW: 甚至于连 Linux kernel io_uring 的作者 Jens Axboe 也给 RocksDB 当外援：
（二）ToplingDB 怎么办ToplingDB 中有三种 SST：Topling Fast Table(SST)极速，一般常驻内存，并且仅用于 L0 和 L1Topling Zip Table(SST)使用可检索内存压缩算法，直接在压缩的数据上执行搜索。压缩率和性能都远高于 RocksDB BlockBasedTable（不管它是用 zstd 还是 lz4/snappy/gzip/bzip）。用于 L2 及更下层Topling Auto Sort Table(SST)允许输入的数据无序，用于 MyTopling(MySQL on ToplingDB) 中索引创建以及批量加载在这三种 SST 中，只有 Topling Zip Table 需要 IO 异步(实现 IO 并发)，如果也按照 RocksDB 那一套来实现，会有诸多问题：如前所述，Cache 命中时，性能反而大幅降低需要的代码修改太多，RocksDB 有全球顶级的强大的研发团队，即便是走在错误的道路上，也可以堆人，堆资源，硬是凭借大力出奇迹，而我们显然不能那样干RocksDB 的这个异步机制仍在 Experiment 状态，不光稳定性存疑，而且处在不断的变化演进中，在它这个异步框架内实现，就要带着它这个包袱，它有 Bug，我们也遭殃，它改了接口，我们也得跟着改按照我事半功倍的信条：改最少的代码，获最大的收益，这个收益，不仅仅是性能上的收益，还有代码的模块化、可读性、可维护性、可复用性……所以，经过仔细思考与权衡，ToplingDB 的 MultiGet 还是得由我自己来亲自实现。（三）实现方案协程分无栈协程和有栈协程，无栈协程理论上性能更好，但是一来需要编译器支持，二来需要修改全链路代码。RocksDB 的 Async IO 实现其实是个有栈协程和无栈协程的混合体。编译器支持还好说，现在主流编译器(gcc,clang,msvc)都支持 C++20 的协程，但是修改全链路代码这是不能忍受的。所以我们必须使用有栈协程，仍然延续之前 TerarkDB 的选择：boost fiber（再加上我的改进）。有栈协程理论上性能不如无栈协程，但是凭借优良的实现，其性能代价（协程切换）已经低到大致等同于一个函数调用。但有栈协程最大的优势其实是几近完美的兼容性：不需要编译器支持，不需要修改现有代码，甚至连现有二进制库都可以完全复用。io 模型上，三年前使用的是 linux aio，现在自然要使用 io_uring，但是对外的函数接口没变，依然是：ssize_t fiber_aio_read(int fd, void* buf, size_t len, off_t offset);
这个函数原型跟 posix pread 完全相同：ssize_t pread(int fd, void *buf, size_t count, off_t offset);
只要上层代码开启多个 fiber 执行 fiber_aio_read，就自动获得了 io 并发的能力，在 MultiGet 中：if (read_options.async_io) {
gt_fiber_pool.update_fiber_count(read_options.async_queue_depth);
size_t memtab_miss = 0;
for (size_t i = 0; i < num_keys; i++) {
if (!ctx_vec[i].is_done())
gt_fiber_pool.push({TERARK_C_CALLBACK(get_in_sst), i}), memtab_miss++;}
while (get_in_sst_cnt < memtab_miss) gt_fiber_pool.unchecked_yield();
} else {
for (size_t i = 0; i < num_keys; i++)
if (!ctx_vec[i].is_done()) get_in_sst(i);}
关键代码，在 fiber_pool 中执行 get_in_sst(i)：gt_fiber_pool.push({TERARK_C_CALLBACK(get_in_sst), i});
get_in_sst 调用 Version::Get（这个函数有 14 个参数，在 RocksDB 中是稀疏平常），完全复用了现有代码，Version::Get 最终会调用到 TableReader::Get，例如 BlockBasedTable::Get，或者 ToplingZipTable::Get，在 ToplingZipTable 中：static const byte_t* // remove error check for simplicity
FiberAsyncRead(void vself, size_t offset, size_t len, valvec
buf->resize_no_init(len);
auto self = (ToplingZipTableReader*)vself;
if (auto stats = self->stats_) {
auto t0 = qtime::now();
fiber_aio_read(self->storeFD_, buf->data(), len, offset);
auto t1 = qtime::now();
stats->recordInHistogram(SST_READ_MICROS, t0.us(t1));} else {
fiber_aio_read(self->storeFD_, buf->data(), len, offset);}
return buf->data();
}
FiberAsyncRead 是个回调函数，会被 topling-zip 的抽象存储接口 BlobStore::fspread_record_append 调用。（四）fiber_aio_read 实现原理接下来，我们看 fiber_aio_read 是怎么使用 fiber 和 io uring 的，io uring 的原理和用法，有很多非常优秀的介绍文章，所以这里我就不再唠叨了。我们把关注点放在 fiber_aio_read 本身。必须注意：只有在一个线程中的多个 fiber 中调用 fiber_aio_read，才能起到预期的 IO 并发的效果，仅仅把 pread 改成 fiber_aio_read 是不行的！fiber_aio_read 核心代码(为简化起见，省略了错误处理)：intptr_t exec_io(int fd, void* buf, size_t len, off_t offset, int cmd) {
io_return io_ret = {nullptr, 0, 0, false};
io_uring_sqe* sqe;
while ((sqe = io_uring_get_sqe(&ring)) == nullptr) io_reap();
io_uring_prep_rw(cmd, sqe, fd, buf, len, offset);
io_uring_sqe_set_data(sqe, &io_ret);
tobe_submit++;
m_fy.unchecked_wait(&io_ret.fctx);
return io_ret.len;}
可以看到，在获取到 sqe 并设置好内容之后，就调用了 m_fy.unchecked_wait，这个函数的作用是挂起当前 fiber，把当前 fiber 的 context 指针放到 io_ret.fctx 中，其作用相当于把当前 fiber 放入 boost fiber 的等待队列（但是代价更低，这个是我对 boost fiber 的一个改进），然后切换到下一个 fiber 继续执行。这里的下一个 fiber，就是线程的主 fiber，于是代码回到 MultiGet 中：gt_fiber_pool.push({TERARK_C_CALLBACK(get_in_sst), i});
的下一行，从而继续把下一个 get_in_sst(i) 放到另一个 fiber 中执行，直到 fiber_pool 中的 fiber 数量上限，或者到达 MultiGet 中的： while (get_in_sst_cnt < memtab_miss) gt_fiber_pool.unchecked_yield();
这两种情况下都会进入 fiber_aio_read 中的另一段代码（为简化起见，省略了错误处理）：void io_reap() {
if (tobe_submit > 0) {
int submitted = io_uring_submit_and_wait(&ring, io_reqnum ? 0 : 1);
tobe_submit -= submitted;
io_reqnum += submitted;
}
while (io_reqnum) {
io_uring_cqe* cqe = nullptr;
io_uring_wait_cqe(&ring, &cqe);
io_return* io_ret = (io_return*)io_uring_cqe_get_data(cqe);
io_ret->len = cqe->res;
io_uring_cqe_seen(&ring, cqe);
io_reqnum--;
m_fy.unchecked_notify(&io_ret->fctx);
}}
有个单独的 fiber 执行执行 io_reap，这其中的 IO 并发来自于 io_uring_submit_and_wait，在其它 fiber (gt_fiber_pool.push 触发的，调用 fiber_aio_read 的 fiber) 中每个 fiber 已经创建了一个 sqe，到这里就通过io_uring_submit_and_wait 把那些 sqe 一次性全部提交，io uring 就在 linux 内核中并发执行这些 io！io_uring_submit_and_wait 返回后，我们就开始收割 io 执行的结果，对于每一个 io 执行的结果(我们自定义的io_return)，我们切换回（m_fy.unchecked_notify(&io_ret->fctx)）这个 io 所在的 fiber 继续执行。以这样的方式，整个执行链路上的代码无需任何改动，具体到我们这个 MultiGet 实现，就是 get_in_sst(i) 调用的Version::Get，Version::Get 的现有代码被我们完全复用了，没有任何改动！对比原版 RocksDB 的 MultiGet 实现，需要的工程量，算上 fiber_aio_read 本身的实现和我对 boost fiber 的改进，百分之一都不到！（五）实测效果我们先用 db_bench 进行测试（将 ReadOptions::async_io 设为 true 或 false）：./db_bench -json sideplugin/rockside/sample-conf/lcompact_enterprise.yaml \
-benchmarks=multireadrandom -num 100000000 -reads 20000 \
-multiread_batched=true -multiread_check=false \
-multiread_async=true -multiread_async_qd=128 -batch_size=128db_bench 测试的数据是 10亿条，数据总量 110G，用 -benchmarks=seqfill 准备数据，使用 ToplingZipTable 压缩后为 16G。对 PageCache 全命中的测试，我们使用的是 64 核 768G内存的物理机，存储是本地 NVMe XFS 文件系统；对 PageCache 不命中的测试，我们使用了一台 4 核 4G 的 VMware 虚拟机，并且通过 NFS 访问远端 NVMe XFS 文件系统。测试结果如下：PageCache 全命中PageCache 不命中async_io = true3.845 micros/op260067 ops/sec0.077 seconds19968 operations;28.8 MB/s(19968 of 19968 found)51.138 micros/op19554 ops/sec1.021 seconds19968 operations;2.2 MB/s(19968 of 19968 found)async_io = false3.829 micros/op261142 ops/sec0.076 seconds19968 operations;28.9 MB/s(19968 of 19968 found)622.804 micros/op1605 ops/sec12.436 seconds19968 operations;0.2 MB/s(19968 of 19968 found)可以看出，在 PageCache 全命中的场景下，ToplingDB async_io 的 MultiGet 和同步 IO 几乎没有差别，而PageCache 不命中的情况下，相差了 11 倍！并且，在 PageCache 全命中的情况下，几乎没有性能退化（RocksDB 的 Async IO 实现在 Cache 全命中的情况下性能有不少退化，见下面截图）。再看下 RocksDB 的测试结果（摘自 RocksDB 官方提交记录）：
ToplingDB 的简单实现，性能远高于 RocksDB 数以万行的复杂实现！这就是大道至简，事半功倍！（六）应用到 MyTopling MRRMyTopling 是把 MySQL 架构在 ToplingDB 之上的云原生数据库，拥有 ToplingDB 的分布式 Compact，以及 CSPP 事务引擎、Topling Zip 可检索内存压缩……，自然也能充分地利用 ToplingDB 的 MultiGet，这在 MySQL 的世界中叫做 MRR（Multi Range Read），简单说就是在一些 Query 中，需要访问多条记录，MySQL 执行规划就认为，先拿到多条记录(ROW)的主键，把这些主键一股脑下推到存储引擎层，由存储引擎来决定如何用尽可能高效的方式拿到这些记录(ROW)，最简单直接的 Query 就是：select from SomeTable where id in (..... / 比如这里有 1000 个 ID */);如果存储引擎不做任何优化，一次一条地拿就可以了，例如对于 MEMORY 存储引擎，因为不牵涉到 IO，一次拿一条，简单直接。但是对于 InnoDB 或 MyTopling 存储引擎，几乎必然会有 IO 操作，MRR 就提供了一个优化 IO 的机会。在 MyTopling 中，自然就是 ToplingDB 的 MultiGet 了，我们用 sysbench 测试，通过设置适当的命令参数，构造了一些会产生 IO，并且触发 MRR 的 Query：sysbench select_random_points run --tables=1 --table_size=200000000 \
--mysql-user=***** --mysql-password=***** --mysql-host=***** \
--mysql-port=3306 --mysql-db=***** --time=300 --threads=10 \
--mysql_storage_engine='rocksdb default charset latin1' \
--rand-type=uniform --random_points=256用这个 sysbench 测试，数据库服务器统一使用 8 核 32G 的规格，对比了几个（在阿里云上运行的）主流 MySQL （变体）及不同存储配置的指标：QPS 对比线程数=4线程数=10QPS 对比线程数=4线程数=10网络存储 MyTopling132193本地 SSD MyTopling7501243网络存储 MyRocks1729本地 SSD MyRocks162351网络存储 InnoDB1434本地 SSD InnoDB158302RDMA存储 PolarDB116285PolarDB 无本地 SSD注：QPS 看着很低，但一次读 256 条，所以 QPS 乘以 256，才是每秒钟读的数据条数。从中可以看到，不管是在网络存储上，还是在本地 SSD 文件系统上，MyTopling 优势特别突出。跟 PolarDB 相比，MyTopling 使用的网络存储是阿里云 NAS，自然没法跟 PolarDB 的 RDMA 存储相比。4 线程时，MyTopling 相比 PolarDB 还勉强有微弱的优势（132 <=> 116），这纯粹是靠软件上的并发 IO 取胜的，到10 线程时，PolarDB 硬件上的优势就无法用软件取胜了！但是本地 SSD 版，MyTopling 就是一枝独秀了！用火焰图来看，一目了然：
我们先聚焦到 MySQL 对 MultiGet 的调用：
图中蓝框之外的部分是为 MRR 准备数据（ID主键），蓝框之内的，是线程主 fiber 中的 MultiGet，我们再聚焦：
MultiGet 中通过 fiber_pool.push 切换到 fiber_pool 中的 fiber 执行 get_in_sst，所以，这个栈中是看不到 get_in_sst 的，get_in_sst 是在第一张图右边的：