前言
存储器是计算机的核心部件之一，在完全理想的状态下，存储器应该要同时具备以下三种特性：
- 速度足够快：存储器的存取速度应当快于 CPU 执行一条指令，这样 CPU 的效率才不会受限于存储器
- 容量足够大：容量能够存储计算机所需的全部数据
- 价格足够便宜：价格低廉，所有类型的计算机都能配备
但是现实往往是残酷的，我们目前的计算机技术无法同时满足上述的三个条件，于是现代计算机的存储器设计采用了一种分层次的结构：
零拷贝direct I/O异步 I/O磁盘高速缓存区PageCacheTLBI/OI/OI/OLinux I/O需要了解的词
页缓存（Page Cache）
32 KB- 虚拟内存
在计算机领域有一句如同摩西十诫般神圣的哲言："计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决"，从内存管理、网络模型、并发调度甚至是硬件架构，都能看到这句哲言在闪烁着光芒，而虚拟内存则是这一哲言的完美实践之一
虚拟内存为每个进程提供了一个一致的、私有且连续完整的内存空间；所有现代操作系统都使用虚拟内存，使用虚拟地址取代物理地址，主要有以下几点好处： - 多个虚拟内存可以指向同一个物理地址
- 虚拟内存空间可以远远大于物理内存空间
- 应用层面可管理连续的内存空间，减少出错
利用上述的第一条特性可以优化，可以把内核空间和用户空间的虚拟地址映射到同一个物理地址，这样在 I/O 操作时就不需要来回复制了
- NFS文件系统
网络文件系统是FreeBSD支持的文件系统中的一种，也被称为NFS；NFS允许一个系统在网络上与它人共享目录和文件，通过使用NFS，用户和程序可以象访问本地文件 一样访问远端系统上的文件 - Copy-on-write
写入时复制（Copy-on-write，COW）是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源
为什么要有DMA
在没有 DMA 技术前，I/O 的过程是这样的：
- CPU 发出对应的指令给磁盘控制器，然后返回
- 磁盘控制器收到指令后，于是就开始准备数据，会把数据放入到磁盘控制器的内部缓冲区中，然后产生一个中断；
- CPU 收到中断信号后，停下手头的工作，接着把磁盘控制器的缓冲区的数据一次一个字节地读进自己的寄存器，然后再把寄存器里的数据写入到内存，而在数据传输的期间 CPU 是被阻塞的状态，无法执行其他任务
整个数据的传输过程，都要需要 CPU 亲自参与拷贝数据，而且这时CPU是被阻塞的；简单的搬运几个字符数据那没问题，但是如果我们用千兆网卡或者硬盘传输大量数据的时候，都用 CPU 来搬运的话，肯定忙不过来 计算机科学家们发现了事情的严重性后，于是就发明了 DMA 技术，也就是直接内存访问（Direct Memory Access） 技术 简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务 具体流程如下图：
- 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态
- 操作系统收到请求后，进一步将 I/O 请求发送 DMA，释放CPU
- DMA 进一步将 I/O 请求发送给磁盘
- 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满
- DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 依然可以执行其它事务
- 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU
- CPU 收到 中断信号，将数据从内核拷贝到用户空间，系统调用返回
在有了DMA后，整个数据传输的过程，CPU 不再参与与磁盘交互的数据搬运工作，而是全程由 DMA 完成，但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器 早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以每个 I/O 设备里面都有自己的 DMA 控制器
传统文件传输的缺陷
有了 DMA 后，我们的磁盘 I/O 就一劳永逸了吗？并不是的；拿我们比较熟悉的下载文件举例，服务端要提供此功能，比较直观的方式就是：将磁盘中的文件读出到内存，再通过网络协议发送给客户端 具体的 I/O 工作方式是，数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入 代码通常如下，一般会需要两个系统调用：
read(file, tmp_buf, len)
write(socket, tmp_buf, len)用户态内核态I/O设备syscall read(切换上下文)1开始DMA拷贝2从磁盘完成拷贝到内核缓存区3CPU拷贝数据到用户缓冲区(切换上下文)4syscall write(切换上下文), CPU拷贝数据到socket缓冲区5开始DMA拷贝6从socket缓冲区完成拷贝到网卡7write返回(切换上下文)8用户态内核态I/O设备read()write()所以，要想提高文件传输的性能，就需要减少用户态与内核态的上下文切换和内存拷贝的次数
如何优化传统文件传输
减少「用户态与内核态的上下文切换」
读取磁盘数据的时候，之所以要发生上下文切换，这是因为用户空间没有权限操作磁盘或网卡，内核的权限最高，这些操作设备的过程都需要交由操作系统内核来完成，所以一般要通过内核去完成某些任务的时候，就需要使用操作系统提供的系统调用函数 而一次系统调用必然会发生 2 次上下文切换：首先从用户态切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行
减少「数据拷贝」次数
前面提到，传统的文件传输方式会历经 4 次数据拷贝；但很明显的可以看到：从内核的读缓冲区拷贝到用户的缓冲区和从用户的缓冲区里拷贝到 socket 的缓冲区」这两步是没有必要的 因为在下载文件，或者说广义的文件传输场景中，我们并不需要在用户空间对数据进行再加工，所以数据并不需要回到用户空间中
零拷贝
那么零拷贝技术就应运而生了，它就是为了解决我们在上面提到的场景——跨过与用户态交互的过程，直接将数据从文件系统移动到网络接口而产生的技术
零拷贝实现原理
零拷贝技术实现的方式通常有 3 种：
- mmap + write
- sendfile
- splice
mmap + write
read()mmap()read()buf = mmap(file, len)
write(sockfd, buf, len)mmapvoid *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);mmap()
具体过程如下：
mmap()write()mmap()read()sendfile
sendfile()#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);read()write()
带有 scatter/gather 的 sendfile方式
scatter/gatherCPU COPY$ ethtool -k eth0 | grep scatter-gather
scatter-gather: on2.4sendfile()- 第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
- 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；
所以，这个过程之中，只进行了 2 次数据拷贝，如下图：
splice 方式
splicesendfilesendfilesplicesocketsocketsendfilesplicesendfilesendfilesplicesplice()Linuxpipe buffersplice()splice()pipe()pipe()splice()DMAsplice()splice()socketDMAsocketsplice()
splicesendfilesplicesendfilesplice零拷贝的实际应用
Kafka
transferTo@Overridepublic
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
return fileChannel.transferTo(position, count, socketChannel);
}sendfile()transferTo()sendfile()Nginx
Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：
http {
...
sendfile on
...
}大文件传输场景
零拷贝还是最优选吗
在大文件传输的场景下，零拷贝技术并不是最优选择；因为在零拷贝的任何一种实现中，都会有「DMA将数据从磁盘拷贝到内核缓存区——Page Cache」这一步，但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多做的一次数据拷贝，造成性能的降低，即使使用了 PageCache 的零拷贝也会损失性能 这是因为在大文件传输场景下，每当用户访问这些大文件的时候，内核就会把它们载入 PageCache 中，PageCache 空间很快被这些大文件占满；且由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来 2 个问题：
- PageCache 由于长时间被大文件占据，其他「热点」的小文件可能就无法充分使用到 PageCache，于是这样磁盘读写的性能就会下降了
- PageCache 中的大文件数据，由于没有享受到缓存带来的好处，但却耗费 DMA 多拷贝到 PageCache 一次
direct I/O那么大文件传输场景下我们该选择什么方案呢？让我们先来回顾一下我们在文章开头介绍DMA时最早提到过的同步 I/O：
I/O
它把读操作分为两部分：
- 前半部分，内核向磁盘发起读请求，但是可以不等待数据就位就返回，于是进程此时可以处理其他任务
- 后半部分，当内核将磁盘中的数据拷贝到进程缓冲区后，进程将接收到内核的通知，再去处理数据
direct I/Obuffer I/Odirect I/Odirect I/Odirect I/Odirect I/O- 内核的 I/O 调度算法会缓存尽可能多的 I/O 请求在 PageCache 中，最后「合并」成一个更大的 I/O 请求再发给磁盘，这样做是为了减少磁盘的寻址操作
- 内核也会「预读」后续的 I/O 请求放在 PageCache 中，一样是为了减少对磁盘的操作
实际应用中也有类似的配置，在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式传输：
location /video/ {
sendfile on;
aio on;
directio 1024m;
}directio使用direct I/O需要注意的点
Linus(Linus Torvalds)"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances." —Linus
Linus地址对齐限制
O_DIRECT会带来强制的地址对齐限制，这个对齐的大小也跟文件系统/存储介质相关，并且当前没有不依赖文件系统自身的接口提供指定文件/文件系统是否有这些限制的信息
blockdev --getsssector sizeblockdev --getpbsz带来这个限制的原因也很简单，内存对齐这件小事通常是内核来处理的，而O_DIRECT绕过了内核空间，那么内核处理的所有事情都需要用户自己来处理，这里贴一篇
O_DIRECT 平台不兼容
LinuxWindowsmacOS不要并发地运行fork和O_DIRECT I/O
O_DIRECT I/ObuffermmapO_DIRECT I/Oforkbuffershmatmmapbuffermadvisebuffer避免对同一文件混合使用 O_DIRECT 和普通 I/O
O_DIRECTI/OI/OI/Odirect I/OmmapNFS协议下的O_DIRECT
NFSO_DIRECTNFSNFSO_DIRECT I/OPage CacheI/OcacheI/OO_DIRECTI/OI/OI/OLinuxNFS在Golang中使用direct I/O
posix_memalignGolangGolangbuffer := make([]byte, 4096)bufferdata- 先分配 4096 + 512 大小的内存块，假设得到的内存块首地址是 p1
- 然后在 [ p1, p1+512 ] 这个地址范围找，一定能找到 512 对齐的地址 p2
- 返回 p2 ，用户能正常使用 [ p2, p2 + 4096 ] 这个范围的内存块而不越界
以上就是基本原理了，具体实现如下：
// 从 block 首地址往后找到符合 AlignSize 对齐的地址并返回
// 这里很巧妙的使用了位运算，性能upup
func alignment(block []byte, AlignSize int) int {
return int(uintptr(unsafe.Pointer(&block[0])) & uintptr(AlignSize-1))
}
// 分配 BlockSize 大小的内存块
// 地址按 AlignSize 对齐
func AlignedBlock(BlockSize int) []byte {
// 分配一个大小比实际需要的稍大
block := make([]byte, BlockSize+AlignSize)
// 计算到下一个地址对齐点的偏移量
a := alignment(block, AlignSize)
offset := 0
if a != 0 {
offset = AlignSize - a
}
// 偏移指定位置，生成一个新的 block，这个 block 就满足地址对齐了
block = block[offset : offset+BlockSize]
if BlockSize != 0 {
// 最后做一次地址对齐校验
a = alignment(block, AlignSize)
if a != 0 {
log.Fatal("Failed to align block")
}
}
return block
}所以，通过以上 AlignedBlock 函数分配出来的内存一定是 512 地址对齐的 唯一的一点点缺点就是在分配较小内存块时对齐的额外开销显得比较大
开源实现
Golang direct I/O- O_DIRECT 模式打开文件：
// 创建句柄
fp, err := directio.OpenFile(file, os.O_RDONLY, 0666)- 读数据
// 创建地址按照 4k 对齐的内存块
buffer := directio.AlignedBlock(directio.BlockSize)
// 把文件数据读到内存块中
_, err := io.ReadFull(fp, buffer)内核缓冲区和用户缓冲区之间的传输优化
zero-copyCPUsendfile()splice()mmapCopy-on-WriteBuffer Sharing写时拷贝 (Copy-on-Write)
mmapCOW (Copy on Write)COWMMUMMUMMUMMUCOWLinuxfork / cloneforkread-only
局限性
COWCOWCPUread-onywrite-onlyCOW的实际应用
Redis 的持久化机制
RedisRedisbgsavebgrewriteaofRedisCOWfork()语言层面的应用
C++ 98std::stringstd::string x("Hello");
std::string y = x; // x、y 共享相同的 buffer
y += ", World!"; // 写时复制，此时 y 使用一个新的 buffer
// x 依然使用旧的 bufferGolangstring, sliceappendcopyappend缓冲区共享 (Buffer Sharing)
Linux I/OI/Oread()write()I/OLinuxI/OMMUTLBI/OTLBI/OFast Buffersfbuffbufsfbufsbuffer poolfbufs总结
I/ODMACPUI/OZero-copyCPU| CPU拷贝 | DMA拷贝 | 系统调用 | 上下文切换 | 硬件依赖 | 支持任意类型输入/输出描述符 | |
|---|---|---|---|---|---|---|
| 传统方法 | 2 | 2 | read/write | 4 | 否 | 是 |
| 内存映射 | 1 | 2 | mmap/write | 4 | 否 | 是 |
| sendfile | 1 | 2 | sendfile | 2 | 否 | 否 |
| sendfile(scatter/gather copy) | 0 | 2 | sendfile | 2 | 是 | 否 |
| splice | 0 | 2 | splice | 2 | 否 | 是 |
PageCachePageCacheI/OI/OPageCachePageCacheI/Odirect I/Odirect I/OLinusI/O