1. 背景
三年前，我还在努力改进曾经的 TerarkDB，其中一个改进就是通过 fiber(Coroutine 协程) 提升 MultiGet 性能。
彼时 linux 的 io uring 还远未成熟，所以使用的是 aio，虽然 aio 仅支持 direct io，但是经过我的改进，MultiGet 仍获得了数量级的性能提升。
2. 方案
2.1. IO 模型，选择 aio
如果放到现在，自然是 io uring，但是三年前，io uring 才刚出来，功能性、稳定性、可靠性都未经过验证，最关键的是，因为太新，别说生产环境，实验环境的 kernel 都不支持，非要用，只能自己去安装最新版 kernel
Linux native aio 的接口非常简洁：
// 创建、销毁 aio 对象：
int io_setup(int maxevents, io_context_t *ctxp);
int io_destroy(io_context_t *ctxp);
// 提交 aio 操作：
int io_submit(io_context_t ctx, long nr, struct iocb *ios[]);
// 收割 aio 结果：
int io_getevents(io_context_t ctx_id, long min_nr, long nr,
struct io_event *events,
struct timespec *timeout);2.2. 协程库
boost fiber 大概是最优秀的(有栈)协程实现了，所以我一开始就选择了它，但是在读 fiber 代码时，还是发现了很多可以优化的点，所以，我对 boost fiber 做了 一些改进（其中包含 call on main stack 功能）。
2.3. MultiGet
很多时候，我们需要一次性查询多个 key ，最典型的，例如在 MySQL 中：
select * from SomeTable where id in (.....);在 MySQL 的查询规划中，这个语句最终会用到 MRR(Multi Range Read)，就是一次性地把多个 id 下推到存储引擎，由存储引擎一次性地查询这些 id。当然，这只是 MRR 最朴素的应用场景，稍微复杂一点的，例如：
select * from SomeTable where index_2nd = ...; # 用二级索引搜索在 RocksDB 中，MultiGet 就是干这个事的，不过在当时的 RocksDB 中，MultiGet 基本上就是顺次执行各个 Key 的 Get，并没有进行任何(针对 IO 的)优化。
但是，MultiGet 这个接口存在的价值，主要是 提供了优化的机会，只要上层使用了这个接口，上层的任务就完成了，至于如何优化，是下层存储引擎的事情。
2.4. 微创手术
做任何事情，最理想方式的都是以最小的投入，获得最大的产出，老祖宗总结了一个词： 事半功倍！
既然是在已有的代码上做这个优化，我的信条就是， 改最少的代码，获最大的收益：
- 用户(使用方)代码无需改动
- 复用现有实现代码
- 复用现有测试代码（单元测试&测试用例）
最终，用户能看到的，只有性能的提升。具体到 MultiGet，我的相关修改，去掉注释和空行， 不到 10行：
这个改进，在 NVMe SSD 的 IO bound 场景下，MultiGet 的性能提升了 10+ 倍！
2.5. 炸掉屎山，建造屎星(shit planet)
如今，RocksDB 已经自己实现了 MultiGet 的 IO 优化，他们先实现了单个 SST 内 多个 Key 查询的优化，所以，在 RocksDB 中有
FileSystem::MultiRead。但是，一个 DB 实例中往往有数千到数万个 SST，MultiGet 中的多个 key 落到同一个 SST 的概率，实在是太低了，所以，即便 SST 使用
FileSystem::MultiRead 实现了相应的 MultiGet，也几乎无法在 DB 层面的 MultiGet 获得收益。
于是，很久以后，RocksDB 通过 folly 的 Coroutine 实现 跨 SST 文件的 IO 优化，查看一下代码，各种相关改动， 以万行计！然而效果实在惨淡(摘自 官方提交记录)：
3. MyTopling & ToplingDB
为了有效地借助开源社区的力量，充分利用开源社区的成果，MyTopling 和 ToplingDB 都紧跟上游最新版，并且遵循 事半功倍的原则，这给我们带来了巨大的收益。但是在 RocksDB 新版的 MultiGet 这里，我们得自己实现一个版本了！