2018/5/18 19:10:24当前位置推荐好文程序员浏览文章

本文从操作系统的角度来解释BIO,NIO,AIO的概念,含义和背后的那些事。本文主要分为3篇。

  • 第一篇 讲解BIO和NIO以及IO多路复使用
  • 第二篇 讲解磁盘IO和AIO
  • 第三篇 讲解在这些机制上的少量应使用的实现方式,比方nginx,nodejs,Java NIO等

磁盘IO

磁盘IO,简单来说就是读取硬盘一类设施的IO。这类设施包括传统的磁盘、SSD、闪存、CD等。操作系统将其统一笼统为”块设施“。所以磁盘IO又能叫做”块IO“。这些设施上的数据一般使用文件系统来组织,所以又能成为”文件IO“。本文统一使用”磁盘IO“这个术语。

簇(sector)和块(block)

对于磁盘的驱动来说,存在一个最小的操作单位。这个单位被称为“簇”(sector)。对磁盘的操作不能小于这个单位,比方整簇读取/整簇写入。比方硬盘的簇很多都是512Byte,而CD上的簇是2KB。

对于Linux来说,虚拟文件系统(VFS)笼统了磁盘设施,统一称为“块设施”(block device)。数据是按照一块块来组织的。操作系统能随机的定位到某个“块”,读写某个“块”。

很不巧,“阻塞”和“块”的英文单词都是“block”,请读者留意区分。

块到簇的转换,是由设施驱动来完成的。一个“块”的大小必需大于等于一个“簇”。并且块的大小必需是簇的整倍数(否则转换起来就太麻烦了)。块的大小一般有512Byte,1KB,2KB等。

在VFS上层的应使用是感受不到“簇”的,他们只可以感受到“块”。同时,对于操作系统在驱动程序之上的层次来说,访问磁盘数据的最小单位是“块”。即,即便你只想读取1个Byte,磁盘也至少要读取1个块;要写入1个Byte,磁盘也至少要写入一个块。

这里简单详情“簇”和“块”,是由于读写磁盘数据要求“块”对齐。下文中会提到。

Page Cache

在虚拟文件系统层之上,是内存。这一层被称为Page Cache。详见下图。

Page Cache和块设施

这个层次是使用页面(Page)来组织的。一般来讲一个页面是4KB,一个页面对应若干个“块”。

Page Cache对于磁盘IO的性可以体现极度重要。比方,当通过write API写入数据到磁盘时,数据先会被写入到Page Cache。此时,这个Page被称为“dirty page”。dirty page会最终被写入到磁盘上,这个过程为称之为“写回”(writeback)。写回往往不会立刻发生。写回可可以因为调使用者直接用相似于fsync这样的API,也有可可以由于操作系统根据某种策略和算法决定自动写回。写回发生之前,假如机器挂了,就有可可以丢失数据。这也是为什么有持久性要求的程序都需要使用fsync来保证数据落地的起因。

当读取数据时,操作系统会先尝试从Page Cache里找,假如找到了就会直接返回给应使用程序。假如找不到,就会触发“页错误”(Page Fault),迫使操作系统去读取磁盘数据,在Page Cache里进行缓存,而后将数据返回给上层应使用程序。

Page Cache的基本维护算法是基于“时间局部性”(Temporal Locality)。下面是wiki的解释:

Temporal locality refers to the reuse of specific data, and/or resources, within a relatively small time duration.

使用人类语言解释就是假设“被访问的数据在短时间内再次被访问的几率会很大”。具体算法一般就是基于Least Recent Use,LRU——即把最不经常访问的Cache删除掉。

“时间局部性“作为通使用规则,能应付大部分情况。但是凡事总有特殊。比方把一个巨大的文件从头读到尾。此时“时间局部性”一定是不起作使用的(已经读取过的数据反而不需要了)。这时就要使用少量定制的手段来定制“如何做Cache”。比方能预取——预先把即将访问的数据读取到Cache;能强制一个Page常驻——手工管理一个Page的存活等。这些工作能由fadvise等api来完成。

大家都知道内存的读写推迟要比磁盘高2~3个数量级。对于磁盘数据,即可以长期的保存在Cache中。这样能极大的提升磁盘IO读取的效率。

应使用程序

Page Cache的上层是应使用程序,就是我们平常写的程序了。

磁盘IO的应使用程序大概长这样:

char buffer[BUF_SIZE];      / buffer /int fd1 = / ... 打开一个文件并取得fd /int fd2 = / ... 打开另一个文件并取得fd /read (fd1, &buffer, BUF_SIZE); / 读文件数据到buffer // processing buffer ... /write (fd2, &buffer, ret_in); / 将buffer数据写入文件 // 假如需要,能调使用fsync(fd2); 将数据刷到磁盘// close fd /

在解决IO数据时,应使用程序总是需要在使用户态分配一段内存空间作为buffer,而后将Page Cache中的数据copy出来进行解决。解决完成后,将数据写回(copy回)到Page Cache。

应使用和Page Cache

假如你留意这个图,就会发现,这里会多额外两次数据的copy(并且是CPU copy)。但是有两种方法能避免这两次copy,分别是mmapsendfile

mmap

mmap能将Page Cache中的内核空间内存地址直接映射到使用户空间中,于是应使用程序能直接对Page Cache中的数据进行读写操作。

内存映射

mmap的一个巨大好处是能让开发人员像是访问常规变量那样随机访问文件中的数据。假如不使用mmap,开发人员就得自己使用lseek去频繁定位文件的位置。这样一来是非常麻烦,代码写的会相当臃肿啰嗦;二是lseek也是系统调使用,频繁用的话会造成大量上下文切换,带来性可以上的无谓损耗。

现实当中,mmap有相当花样的玩法,能实现多进程数据共享和通讯,实现跨进程锁等。但这些功可以不是本文的重点就不开展了。

sendfile

sendfile能直接将Page Cache中某个fd的一部分数据传递给另外一个fd,而不使用经过到应使用层的两次copy。值得注意的是,sendfile的原始fd必需是一个磁盘文件对应的fd;而其目标fd能是磁盘文件,也能是socket。当为socket时,sendfile就非常高效的实现了一个功可以——通过网络serving文件。一般称这种实现为“Zero Copy”。

其实这里还是会copy,只不过只有DMA copy,没有CPU copy,不白费CPU

sendfile实现Zero Copy

上图是一个用sendfile将一个文件直接发到网络的示用意。调使用sendfile使得文件数据进入到Page Cache,而后让网卡直接从Page Cache中获取数据发送给网络。期间不出现任何CPU Copy。假如调使用sendfile时,数据已经在Page Cache了,就会被直接用。

但是sendfile也有一个严重的缺点。由于数据是两个fd在内核直接传输的,所以无法做任何修改。你只可以原封不动的传输原始的数据文件。一旦你想在数据上做少量额外的加工,就无法用sendfile。比方磁盘上存储的是原始的文件,而你想压缩文件后再传输给socket,就必需放弃sendfile,老老实实的把文件读到使用户态buffer,而后做压缩解决,再写回到内核态的socket buffer。

Direct IO

上面详情的是使用了Page Cache的IO一般被称为Buffered IO。之所以不叫Cached IO,是由于早年Linux的磁盘iOS设计中在Page Cache 里还有一个内部的”内核buffer“。在Linux 2.6之后,这个设计被统一到了只用Page。然而,Buffered IO的名字被保留了下来。

与Buffered IO相对的,是Direct IO。即应使用程序直接读写块设施,不再经过Page Cache。

Direct IO

要用这种IO,只需在打开文件时,添加一个O_DIRECT标记。

int fd = open("path/to/the/file", O_DIRECT | O_RDWR);

相比“Buffered IO”,Direct IO必然会带来性可以上的降低。所以Direct IO有特定的应使用场景。比方,在数据库的实现中,为了保证数据持久,写入新数据到WAL(Write Ahead Log)必需直接写入到磁盘,不可以等待。这里使用Direct IO来实现WAL就非常理想。

用Direct IO的另外一种场景是,应使用程序对磁盘数据缓存有特别定制的需要,而常规的Page Cache的各种策略并不可以满足这种需要。于是开发人员能自己设计和实现一套“Cache”,配合Direct IO。毕竟最熟习数据访问场景的,是应使用程序自己的需求。

块对齐

然而,Direct IO有一个很大的问题是要求假如是写入到磁盘,开发者必需自行保证“块对齐”。即write时给的buffer的offset和size要恰好与VFS中的“块”对应,不然就会得到EINVAL错误。假如使用了“Buffered IO”,Page Cache内部即可以自动搞定对齐这件事情了。没有Page Cache,对齐要就得自己做。比方,需要手工调使用posix_memalign分配块对齐的内存地址。

磁盘IO的优化

除非使用Direct IO,对于磁盘IO的优化主要在读取操作上。这是由于写入时总是写到Page Cache,而写内存比写磁盘要高效的多。从业务上讲,一般来讲上传文件的请求量要远远小于获取文件(图片、html、js、css……),所以在Web场景下,对磁盘IO的优化的主要思路其实很简单——尽量保证要读取的文件在内存里,而不是取磁盘上读取。假如数据已经到了Page Cache,你能

  • 选择使用read将其从Page Cache读取到应使用程序的buffer,而后做后续解决。
  • 选择使用sendfile直接将数据复制到另外一个fd里(另外一个文件或者者socket)
  • 选择使用mmap直接读写操作

但假如数据没有到Page Cache,read可可以就会“卡”一下(尽管操作系统并不认为这是阻塞)。对于高性可以服务,这可可以是无法接受的的。我们需要一种不会“卡”当前线程的磁盘数据读取方式。

正如第一篇文章所说,在Linux中,磁盘IO不支持NON_BLOCKING模式。但是Linux提供了磁盘的异步IO接口(Asynchronous IO,AIO)。

AIO

Linux中有两套“AIO”接口。这两套接口都只支持磁盘IO,不支持网络IO。

POSIX AIO

第一套被称作POSIX AIO。顾名思义,这套接口是POSIX标准规定的。这套AIO的接口的定义能参考这里。其大致的用方式是:

  1. POSIX AIO使用信号(signal)来通知进程IO完成了。所以要先注册一个IO完成时对应的信号的handler。
  2. 使用aio_read或者者aio_write来发起要读/写的操作。这个接口会立刻返回。
  3. IO完成后,信号被触发,相应的handler会执行。
  4. 你也能选择不用信号,而主动调使用aio_suspend来主动等待IO的完成,就像第一篇文章中的select那样。

POSIX AIO还支持使用线程来做通知,但这需要额外解决线程协作的问题。

这套接口没有得到广泛的用,起因是其有很大的局限性——这套接口并不可以算是"真・AIO"。这套接口是完全在使用户态实现的(libc),完全没有深入到操作系统内核中。

此外,使用信号做AIO的触发在工程中有很多问题。信号是一个“数字”,而且是全局有效的。所以比方你使用POSIX AIO实现了一个lib,选使用数字M做信号;但是你无法阻止其余人使用POSIX AIO实现另外一个lib,也选使用数字M做信号。这样假如一个程序同时使用了两套lib,就会彼此干扰。POSIX AIO无法实现相似于epoll中能创立多个epoll fd,彼此隔离的用方式。

假如使用aio_suspend,就不满足用AIO的最初目标。你还是得让程序主动“等”一下。并且aio_suspend并不支持eventfd(下文会讲到为什么eventfd很重要)。

此外POSIX AIO由于是POSIX指定的标准,所以其存在的一个重要意义是不同操作系统的实现要一致,便于跨平台用。但实际上各个操作系统对此标准实现的相当不一致(尤其是MacOS),所以这个标准实际上没有什么使用处。能参考这篇吐槽。

所以,对于POSIX AIO大家看看就好。Linux下实际用比较多的是Linux AIO。

Linux AIO

Linux中的另外一套AIO接口被称为Linux AIO,是Linux在内核实现的一套AIO接口。这套是"真・AIO"。接口的详细使用法能参考这里。我这里给出一个极度精简版的例子,里面所有的错误解决都被我忽略了,只是想表现一下Linux AIO的用方式:

aio_context_t ctx;struct iocb cb;struct iocb cbs[1];char data[4096];struct io_event events[1];int ret;int fd = / 打开一个文件,取得fd /;ctx = 0;ret = io_setup(128, &ctx); // 初始化一个同时解决最大128个fd的aio ctx    / 初始化 IO control block /memset(&cb, 0, sizeof(cb));cb.aio_fildes = fd;cb.aio_lio_opcode = IOCB_CMD_PWRITE; // 设置要“写入”cb.aio_buf = (uint64_t)data; // aio使用的buffercb.aio_offset = 0; // aio要写入的offsetcb.aio_nbytes = 4096; // aio要写入的字节个数cbs[0] = &cb;ret = io_submit(ctx, 1, cbs); // 提交io进行异步解决/ 等待aio完成 /ret = io_getevents(ctx, 1, 1, events, NULL);/ 对events进行解决 /io_destroy(ctx);

大意是:

  • io_setup创立一个AIO的上下文aio_context_t(就像epoll会有一个fd)
  • 初始化iocb结构体(io control block),每一个要进行AIO的操作都要一个对应的iocb数据
  • 使用io_submitiocb提交(支持提交多个)。接口会立刻返回。而后,你的程序即可以做其余事情了。
  • 希望解决IO事件时,调使用io_getevents。该接口会阻塞。假如IO事件完成了,就可以拿到events,于是能后续解决数据了。
  • 最终调使用io_destroy把ctx清除掉。

这套接口在Linux内核中实现,看上去靠谱多了。但是这套接口有三个比较令人郁闷的问题。

第一个问题是,它只支持Direct IO的IO操作。也许这套接口是专门给数据库领域专门定制的(更多的人会吐槽这个接口的作者脑筋有问题)。虽然Linux社区有很多争论和提案(比方这里)。但是现状就是只有Direct IO被支持。这就意味着,选择用了Linux AIO就无法享受Page Cache带来的好处;此外,只需用Linux AIO,就意味着必需自己做块对齐(见上文Direct IO的详情)。

BSD系统的AIO接口是支持buffered IO的

第二个问题是,这套接口支持的功可以有限,比方对于fsyncstat等API,压根就不可以真的做到异步。此外Linux AIO对少量特定的文件系统支持不好(比方ext4,在这种操作系统上调使用io_submit,还是会“卡”)。

第三个问题是io_getevents,它和epoll一起用会让程序有两个阻塞点。这样程序就没法写了。Linux提供了eventfd处理这个问题。

用eventfd协调epoll和Linux AIO

假如在Linux下编写一个高性可以文件服务器,就需要同时使用到epoll和Linux AIO。但是epoll_waitio_getevents就会引入两个阻塞点,这样,等待文件IO的时候,网络请求就会被推迟。这可不是我们希望的。

eventfd能帮助把两个阻塞点二合为一。eventfd,顾名思义,就是表达事件的fd。它的本意是利使用fd来简化跨进程的通讯——比方AB两个进程共享同一个eventfd,A进程对eventfd写入,B进程就可以感知到。当然,eventfd也可以在同一个进程里使用。eventfd可以协调epoll和Linux AIO是由于:

  • epoll支持监听eventfd,并且
  • Linux AIO中被提交的events假如完成,就会触发eventfd,于是监听该eventfd的epoll就可以察觉到

这样对于同时用eventfd和Linux AIO的程序即可以把阻塞点统一到epoll_wait上。下面是一个例子(我仍然忽略所有错误解决,尽量简化):

int efd, fd, epfd;io_context_t ctx;struct timespec tms;struct io_event events[NUM_EVENTS];struct iocb iocbs[NUM_EVENTS];struct iocb iocb;int i, j, r;void buf;struct epoll_event epevent;  efd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC); // 用“eventfd”系统调使用创立一个eventfd实例fd = open(TEST_FILE, O_RDWR | O_CREAT | O_DIRECT, 0644); // 打开一个要真实操作的文件    ctx = 0;io_setup(128, &ctx);posix_memalign(&buf, 512, 1024); // 对齐buffer  for (i = 0, iocb = iocbs; i < NUM_EVENTS; ++i, ++iocb) {    io_prep_pread(&iocb, fd, buf, RD_WR_SIZE, i  RD_WR_SIZE);    io_set_eventfd(&iocb, efd); // 对于这个AIO注册eventfd    io_set_callback(&iocb, aio_callback); // 假设有这么个回调函数}io_submit(ctx, NUM_EVENTS, iocbps); // 提交所有的iocbepfd = epoll_create(1); // 创立epoll fdepevent.events = EPOLLIN | EPOLLET;epevent.data.ptr = NULL;epoll_ctl(epfd, EPOLL_CTL_ADD, efd, &epevent); // 让epoll监听eventfd  i = 0;while (i < NUM_EVENTS) {    uint64_t finished_aio;        epoll_wait(epfd, &epevent, 1, -1); // epoll阻塞,开始等待    / epoll_wait 返回了,说明eventfd有事发生了 /    read(efd, &finished_aio, sizeof(finished_aio)); // eventfd的值是这次AIO完成事件的个数    printf("已经完成的IO个数: %"PRIu64"\n", finished_aio);    while (finished_aio > 0) {        tms.tv_sec = 0;        tms.tv_nsec = 0;        / 既然AIO已经完事了,调使用io_gevents就会立刻返回了,不会阻塞 /        r = io_getevents(ctx, 1, NUM_EVENTS, events, &tms);         if (r > 0) {            // 解决AIO的事件            i += r;            finished_aio -= r;        }    }}

上面的例子首先创立了一个eventfd,并且挂到了AIO上下文中。而后epoll_wait监听这个eventfd。在现实中,epoll能同时监听此eventfd和所有其余socket的fd。一旦IO完成,eventfd被触发,epoll_wait返回。程序即可以调使用io_getevents,这时铁定是不会阻塞的,所以能立刻拿到返回的事件,并作解决。

反思AIO

上面探讨了这么多操作系统接口层面上的AIO,有很多细节和不完善的。但是,AIO在概念上却很简单,意思是通过一个回调解决数据。比方在nodejs中,读取文件的使用法能非常清晰的反映出什么才是AIO。

const fs = require(fs); // 引入fs这个包fs.read(/path/to/file, function(data) {    // 解决文件的数据    console.log(文件数据解决完成);});console.log(开始读取文件);

程序员能指定要读取一个文件,并且指定当读取完成后要解决的函数。这个指定立刻执行,不会等待文件的读取。这个模式能清晰的反映出我们脑海中那个理想的AIO的样子。

但是现实是很悲催的,由于操作系统层面的AIO没法变成理想中的样子。

  • 操作系统的AIO接口只支持文件操作。对于网络,需要使用epoll这样的IO多路复使用技术。假如要统一网络和磁盘IO都能AIO就必需在上层进行封装,屏蔽掉操作系统这么不一致的细节(比方libuv就是这么干的)。
  • 因为系统调使用并不只直接支持”回调”(“信号”在工程上难以应使用于IO回调这个场景,不算数),程序员需要自行用io_getevents这样的API来主动等事件。在操作系统层面上,可以做的最舒服的就是统一使用epoll_wait做这个“等事件”的核心。这时需要借助eventfd。POSIX AIO并不支持eventfd,所以尽管有这么套接口,但是一般没机会使用。
  • Linux AIO只支持Direct IO,所以无法利使用Page Cache。所以现实当中,使用不使用是要做取舍的(nginx有一个选项aio就是配置这个功可以的,见这里)。
  • Linux AIO不可以100%实现所有文件操作api都可以“异步”。

所以在操作系统上这个级别上,AIO非常的“别扭”

基于以上的这些问题,一般上层(nodejs,Java NIO)都会选择使用线程池+BIO来模拟文件AIO。好处是:

  • BIO这一套接口非常完备,文件IO除了read,write,还有stat,fsync,rename等接口在现实中也是经常需要”异步“的;
  • 编程容易。看看上面的例子,是不是非常容易晕。而这些已经是非常简化的例子了,现实中的代码要解决相当多的细节;
  • 不使用在AIO和Buffered IO中做取舍。BIO天然能利使用Page Cache来提高性可以;
  • 容易跨平台。不同操作系统的线程实现和BIO的实现基本上完备一致,不会像AIO那样细节差异相当巨大。

再下一篇文章中,会详情上层系统的高性可以IO部分是如何用操作系统API的。


本文来自大宽宽的碎碎念。假如觉得本文有戳到你,请关注/点赞哦。

网友评论