零拷贝并非万能解决方案：重新定义数据传输的效率极限

PageCache有什么作用？

在我们前面讲解零拷贝的内容时，我们了解到一个重要的概念，即内核缓冲区。那么，你可能会好奇内核缓冲区到底是什么？这个专有名词就是PageCache，也被称为磁盘高速缓存。也可以看下windows下的缓存区：如图所示：

零拷贝进一步提升性能的原因在于 PageCache 技术的使用。接下来，我们将详细探讨 PageCache 技术是如何实现这一目标的。

读写磁盘相比读写内存的速度慢太多了，但我们可以采取一种方法来改善这个问题，即将磁盘数据部分缓存到内核中，也就是将其存储在PageCache缓存区中。这个过程实际上是通过DMA（直接内存访问）控制器将磁盘数据拷贝到内核缓冲区中。

然而，需要注意的是，由于内存空间较磁盘空间有限，因此存在一系列算法来确保pageCache占用的内存空间不过大。我们在程序运行时都知道存在一种「局部性」，即刚刚被访问的数据在短时间内很可能再次被访问到，概率很高。因此，pageCache被用作缓存最近访问的数据。可以将pageCache看作是Redis，而磁盘则类似于MySQL。此外，pageCache还使用了内存淘汰机制，在内存空间不足时，会淘汰最近最久未被访问的缓存。

当在项目中使用 Redis 时，你一定知道如何使用它。和 Redis 类似， PageCache 的工作原理也是一样的。在进程需要访问数据时，它会首先检查 PageCache 是否已经存储了所需的数据。如果数据已经存在于 PageCache 中，内核会直接返回数据；如果数据未被缓存，则会从磁盘读取并将数据缓存到 PageCache 中，以备下次查询时使用。这种方式可以有效提高访问效率。

然而，pageCache还具有另一个优点，即预读功能。当访问并读取磁盘数据时，实际上需要定位磁盘中的位置。对于机械硬盘而言，这意味着磁头必须旋转到数据所在的扇区位置，然后开始顺序读取数据。然而，旋转磁头这种物理操作对计算机而言非常耗时。为了降低其影响，就出现了预读功能。通过预读功能，可以提前预读下一扇区的数据，减少等待磁头旋转的时间。

比如read方法需要读取32KB的字节的数据，使其在读取32KB字节数据后，继续读取后面的32-64KB，并将这一块数据一起缓存到pageCache缓冲区。这样做的好处在于，如果后续读取需要的数据在这块缓存中命中，那么读取成本会大幅降低。可以类比于redis中提前缓存一部分分布式唯一id用于插入数据库时的分配操作，这样就无需每次插入前都去获取一遍id。然而，一般情况下，为了避免可能出现的"毛刺"现象，我们通常会使用双缓存机制来处理。这个双缓存机制可以进一步优化读取操作的效果。

因此，PageCache的优点主要包括两个方面：首先，它能够将数据缓存到PageCache中；其次，它还利用了数据的预读功能。这两个操作极大地增强了读写磁盘时的性能。

但是，你可以想象一下如果你在传输大文件时比如好几个G的文件，如果还是使用零拷贝技术，内核还是会把他们放入pageCache缓存区，那这样不就产生问题了吗？你也可以想一下如果你往redis缓存中放了一个还几个G大小的value，而且还知道缓存了也没用，那不就相当于redis形同虚设了吗？把其他热点数据也弄没了，所以pageCache也有这样的一个问题，一是大文件抢占了pageCache的内存大小，这样做会导致其他热点数据无法存储在pageCache缓冲区中，从而降低磁盘的读写性能。此外，由于pageCache无法享受到缓存的好处，还会产生一个DMA数据拷贝的过程。

因此，最佳的优化方法是针对大文件传输时不使用pageCache，也就是不使用零拷贝技术。这是因为零拷贝技术会占用大量的内存空间，影响其他热点数据的访问优化。在高并发环境下，这几乎肯定会导致严重的性能问题。

大文件传输用什么方式实现？

那针对大文件的传输，我们应该使用什么方式呢？

让我们首先来观察最初的示例。当调用read方法读取文件时，进程实际上会被阻塞在read方法的调用处，因为它需要等待磁盘数据的返回。如下图所示：

在没有使用零拷贝技术的情况下，我们的用户进程使用同步IO的方式，它会一直阻塞等待系统调用返回数据。让我们回顾一下之前的具体流程：

应用程序发起read系统调用，用户进程开始进行阻塞等待结果返回。
此时内核会向磁盘发起I/O请求，磁盘收到请求后，开始寻址。当磁盘数据准备好后，就会向内核发起I/O中断，告知内核磁盘数据已经准备好。
内核收到中断信号后，将数据从磁盘控制器缓存区拷贝到pageCache缓冲区。
最后，内核会将pageCache中的数据再次拷贝到用户缓冲区，也就是用户态的内存中，然后read调用返回。

我们知道，既然有同步IO，就一定有异步IO来解决阻塞的问题。异步IO的工作方式如下图所示：

它将读操作分为两个部分：

第一部分是用户进程发起IO请求给内核，然后进程就不再关心该IO操作，而是继续处理其他任务。
第二部分是当内核接收到中断信号后，将数据直接拷贝到用户缓冲区，并通知用户进程操作成功。然后用户进程开始处理数据。

我们发现在这个过程中，并没有涉及到将数据拷贝到pageCache中，因此使用异步方式绕开了pageCache。直接IO是指绕过pageCache的IO请求，而缓存IO是指使用pageCache的IO请求。通常，对于磁盘而言，异步IO只支持直接IO。

正如前面所提到的，对于大文件的传输，不应该使用PageCache，因为这可能会导致PageCache被大文件占据，从而使得"热点"小文件无法充分利用PageCache的优势。

因此，在高并发的场景下，对于大文件传输，我们应该采用"异步I/O + 直接I/O"的方式来代替零拷贝技术。

直接I/O有两种常见的应用场景：

首先，如果应用程序已经实现了磁盘数据的缓存，就不需要再次使用PageCache进行缓存，这样可以减少额外的性能损耗。例如，在MySQL数据库中，可以通过参数设置来开启直接I/O，避免重复的缓存操作，默认情况下是不开启的。
其次，在传输大文件时，由于大文件很难命中PageCache的缓存，而且会占满PageCache导致"热点"文件无法充分利用缓存，增加了性能开销。因此，在这种情况下，应该使用直接I/O来绕过PageCache的缓存，以提高性能。

需要注意的是，直接I/O绕过了PageCache，因此无法享受内核的两项优化。

首先，内核的I/O调度算法会在PageCache中缓存尽可能多的I/O请求，然后将它们合并成一个更大的I/O请求发送给磁盘，以减少磁盘的寻址操作。
其次，内核会预读后续的I/O请求并将其放入PageCache中，同样是为了减少对磁盘的操作。这些优化在直接I/O中无法享受到。

于是，当我们需要传输大文件时，我们可以利用异步I/O和直接I/O的组合来实现无阻塞的文件读取。这种方式可以有效避免PageCache的影响，提高文件传输的效率。

因此，在文件传输过程中，我们可以根据文件的大小来选择不同的优化方式，以提高传输效率。对于大文件，使用异步I/O和直接I/O可以避免PageCache的影响；而对于小文件，则可以使用零拷贝技术来减少数据拷贝次数，提高传输速度。

在Nginx中，我们可以通过以下配置来根据文件的大小选择不同的优化方式：

location /video/ { 
    sendfile on; 
    aio on; 
    directio 1024m; 
}

在这个配置中，我们开启了sendfile选项，这允许Nginx使用零拷贝技术来传输文件。同时，我们也启用了aio选项，这使得Nginx可以使用异步I/O来提高文件传输的效率。

而通过设置directio参数为1024m，我们告诉Nginx当文件大小超过1024MB时，使用直接I/O来进行文件传输。这意味着在传输大文件时，Nginx将使用异步I/O和直接I/O的组合来实现无阻塞的文件读取，避免了PageCache的影响。而对于小文件，Nginx将继续使用零拷贝技术，以减少数据拷贝次数，提高传输速度。