【译】Linux不同的IO访问方式中，Scylla的选择和依据-CSDN博客

【原文】http://www.scylladb.com/2017/10/05/io-access-methods-scylla/
【译文】
大多数服务应用开发者考虑IO时会重点考虑网络IO，因为他们访问的主要资源都是基于网络的，如数据库、对象存储或其他微服务。而数据库开发者则必须考虑文件IO。本文描述了候选方式和如何权衡，以及为什么Scylla选择异步direct IO（AIO／DIO）作为访问访问。

一、访问文件的候选方式

一般Linux服务器有四种访问文件的方式：read/write, mmap, Direct I/O (DIO) read/write, 和异步直接direct I/O (AIO/DIO).

1.1 传统read/write

应用已久的传统方式是使用read和write两个系统调用。在现代的实现中，系统调用read（或其变种pread，readv，preadv等）访问内核，读取一段文件，拷贝数据至调用的进程地址空间。如果所有要访问的数据都在页缓存中，内核会直接拷贝，并立即返回；否则，它需要调度磁盘以读取所需的数据到页缓存中，并阻塞调用线程，当数据可用时，它会恢复线程，并拷贝数据。另一方面，系统调用write会拷贝数据到页缓存中，内核会在某个时间将页缓存写回到磁盘。

传统read/write

1.2 Mmap

一种更现代的替代方案是，以内存映射的方式，使用mmap系统调用，将文件映射到应用程序地址空间中。该操作的效果是，一段地址空间直接对应包含文件数据的页缓存。这个准备步骤完成后，应用程序可以使用进程内存读写指令来访问文件数据。如果请求的数据碰巧在缓存中，内核完全被旁路，读写以内存级速度完成。如果缓存没有需要的数据，则会触发页错误，内核将活动线程变成休眠状态，因为此时该线程需要去读取数据到内存页中。当数据最终可用时，内存管理器受程序控制，最新读取到数据可访问时，相应线程会被唤醒。

mmap

1.3 Direct IO（DIO）

传统的read/write和mmap都需要内核页缓存和内核调度IO。当应用程序希望自己调度IO时（原因稍后解释），它可以使用direct IO。这需要使用标志O_DIRECT来打开文件；进一步的工作是使用通用的读写系统调用，但它们的行为现在会有变化；不访问内存后，会该用直接访问磁盘，这意味着调用线程会被无条件的置为休眠状态。而且磁盘控制器会直接拷贝数据到用户空间，即旁路内核。

Direct IO

1.4 异步Direct IO（AIO/DIO）

异步Direct IO相对于Direct IO有改进，其行为相似，但不阻塞调用线程。应用程序线程使用io_submit系统调用调度direct IO操作，但该线程并不会被阻塞；IO操作与线程执行同时进行。使用独立的系统调用io_getevents来等待结果，并在IO操作完成后收集结果。像DIO一样，内核页缓存也被旁路，磁盘控制器负责拷贝数据到用户空间。

异步Direct IO

二、理解取舍平衡

不同访问方法拥有一些相同的特征，也有一些差异。表1总结来这些特征，具体见下表。

Characteristic	R/W	mmap	DIO	AIO/DIO
Cache control	kernel	kernel	user	user
Copying	yes	no	no	no
MMU activity	low	high	none	none
I/O scheduling	kernel	kernel	mixed	user
Thread scheduling	kernel	kernel	kernel	user
I/O alignment	automatic	automatic	manual	manual
Application complexity	low	low	moderate	high

2.1 缓存控制

对于read/write和mmap，缓存是内核的职责。大部分系统内存被交给页缓存。内核决定在内存不足时哪个页被淘汰，哪些页需要回写至磁盘，哪些需要预读。应用程序可以使用madvise和fadvise来为内核提供一些指示。

由内核控制缓存的最大优势在于，内核开发者们已经投入几十年和巨大精力以优化缓存算法。这些算法已经被成千上万的不同应用程序使用，且整体而已都是很有效的。然而不足是，这些算法是面向通用目标，没有针对具体应用而优化。内核必须猜测应用程序下一步的动作，既是应用程序知道完全不同，它也没有办法帮助内核猜的更准确。结果是页被错误的淘汰，IO以错误的顺序调度，或者预读的数据在近期不会被访问。

2.2 拷贝和MMU活动

mmap方式的一个好处是，如果数据在内存中，内核会被彻底跳过。内核不需要从内核空间拷贝数据到用户空间或反向拷贝，这样就能减少处理器周期的消耗。这还会改善负载，最大化利用缓存（例如，当存储大小比RAM大小接近1:1）。

当数据不在缓存中，mmap会表现较差。当存储大小比RAM大小明显大于1:1时，这种现象尤会发生。每个载入缓存的页都会引起另一页的淘汰。这些页必须插入页表或从中移除，内核必须扫描页表来找到非活动的页，并把它们作为待淘汰的候选。另外，mmap需要为页表分配内存。在x86处理器上，这会需要0.2%的映射文件大小的内存。这看起来很小，但如果应用程序使用的存储与内存的比达到100:1时，结果是，20%的内存被用来存储页表（0.2% * 100）。

2.3 IO调度

内核控制缓存（mmap和read/write）的问题之一是，应用程序失去对IO调度的控制。内核选择它任何合适的数据块，调度对其的读写。这会导致以下的问题：

写风暴：当内核规划大规模写时，磁盘会忙一段时间，进而导致读延迟。
内核不能区分重要和不重要的IO。后台IO任务会挤垮前台任务，导致它们的延迟。

借助绕开内核页缓存，应用程序会承担IO调度的压力。这并不意味着问题被解决，但意味着问题可以被解决，只要投入足够的重视和努力。

使用Direct IO时，每个线程控制何时执行IO。而内核控制线程运行，以便内核和应用程序共同承担IO工作。使用AIO/DIO，应用程序完成控制何时执行IO。

2.4 线程调度

IO密集型应用程序使用mmap或read/write时不能猜出其缓存的命中率。因此，必须运行大量线程（显著大于所运行的机器的核数）。使线程过少时，它们可能都在等待磁盘运动，处理器利用率会很低。由于每个线程都需要等待磁盘IO，运行的线程数大致为存储子系统并发数乘以一个小系数，以保持磁盘能满负荷运转。如果缓存命中率很高时，这些大数量的线程彼此之间会竞争有限的CPU核数。

使用direct IO，这个问题会得到一定缓和，因为应用程序知道何时线程被IO阻塞、何时能运行，所以应用程序可以根据运行环境，调整运行的线程数。

使用AIO/DIO,应用程序完全控制运行的线程和等待的IO（二者完全隔离），所以它能轻松调整内存、磁盘的使用。

2.5 IO对齐

存储设备属性之一是块尺寸，所有IO必须以块大小的整数倍运行，通常是512或4096字节。使用read/write或mmap时，内核自动对齐；小规模读写会被内核扩展至整个块。
使用DIO时，由应用程序来对齐块。这带来了一定的复杂度，但也提供了一个好处：当512字节对齐就足够时，内核通常需要4096字节对齐，但用户应用程序使用DIO就可以用512字节对齐的方式读取，从而节省小对象的传输带宽。

2.6 应用程序复杂度

前面讨论IO密集型应用程序优先选择AIO/DIO，这个方式伴随着一个显著的成本：复杂度。为应用程序设置缓存管理职责，意味着它能比内核更好的做出选择，做出这些选择需要更少的成本。然而，这些算法需要编写和测试。使用异步IO需要应用程序支持回调方式、协程、或其他相似的方法，经常需要降低很多可用库的复用性。

三、Scylla和AIO/DIO

对于Scylla，我们选择更高性能的选项，AIO/DIO。为了隔离一些涉及的复杂度，我们写了Seastar，这是一个面向IO密集型应用的高性能框架。Seastar抽象了执行AIO的细节，为网络、磁盘、多核通讯提供了通用API。它也提供了回调、协程风格的声明管理，以适应不同的使用用例。

不同领域的Scylla关注不同IO使用方式：

压缩使用应用级预读和后写以提高吞吐量，但绕开应用级缓存是缘于设定其低命中率，同时避免冷数据的冲击）。
查询使用应用控制预读和应用级缓存。应用控预读阻止提前预读，是由于我们提前知道数据在磁盘上的边界。应用级缓存使我们不只可以缓存从磁盘读取的数据，也可以将多个文件的数据合并成一个缓存项。
小规模读按512字节对齐，以减少总线数据传输和延迟。
Seastar IO调度器允许我们动态控制压缩和查询的IO率，以满足用户服务等级协议SLA。
独立的IO调度类使commitlog获得需要的带宽，而不会被读抢占。

如果应用直接驱动NVMe以绕过内核，那么AIO/DIO将会是一个好的起点。这也是未来Seastar的特性。