Zero Copy又是提升IO性能的一个技术，Kafka在消费消息的时候就利用了Zero Copy技术。我们来看看最普通的，利用Direct IO实现的传输文件的网络发送代码:
fd_file = opened file description
fd_socket = opened socket description
buffer = application bufffer
read(fd_file, buffer,...) // read data from local file, 2 times copy
write(fd_socket, buffer,...) // write data to socket, 2 times copy
fd_socket = opened socket description
buffer = application bufffer
mmap(fd_file, buffer,...) // read data from local file, 1 times copy
write(fd_socket, buffer,...) // write data to socket, 2 times copyc
程序员应该了解的操作系统各种IO知识
对于现在流行的什么大数据，分布式，消息队列等互联网系统，I/O是绕不过去的一个话题，之前也写过网络编程相关的IO话题 https://github.com/AlexiaChen/AlexiaChen.github.io/issues/79， 但是这次打算更加深入地讨论下。
Buffered I/O 和 Direct I/O
一般开发者或许没有注意到这两者的区别，缓冲IO和直接IO是不太一样的：
缓冲IO实际上就是用户层还做了一个用户层的缓冲区，直接IO没有用户层缓冲区，但是操作系统内核的缓冲区还是有的。一般就是这两个不一样的地方。性能上有一定差距。
拿Linux来说，内核缓冲区其实也就是内核空间的一段buffer，只是这段buffer一般是以页为单位，Linux会把磁盘上的数据以页为单位缓存在操作系统内核中的内存里，一般来说，一个页是4K大小。
缓冲IO的读或写都要经过： 应用程序内存->用户缓冲区->内核缓冲区->磁盘， 其中的数据流转一次，从逻辑上看，有3次数据拷贝。内存中的数据拷贝大家都知道是很耗时的。高性能系统可能会压榨这里
直接IO的读或写都要经过： 应用程序内存->内核缓冲区->磁盘，有2次数据拷贝，性能相对要高。
所以你可以大概想到了，fflush只是把用户缓冲区的数据刷到内核缓冲区里，而fsync则是把内核缓冲区的数据刷到磁盘。
数据库的很多对事务的一致性和持久性底层实现确实依赖了fsync来“保证”数据落盘（fysnc等待落盘才返回，不信你可以搜LevelDB，SQLite，Redis等各种存储系统的源码，肯定能搜到fsync）。
但是从物理世界的角度看，fsync其实不是100$%可靠的，因为它只是把内核缓冲区的数据刷到磁盘的硬件缓冲区中，万一磁盘的磁头还没有把硬件缓冲区的数据写到磁盘上呢？这样数据也就丢失了。不过你可以暂时认为，fsync大部分情况是可靠的就可以了。你可以就认为，一旦fsync有返回，数据肯定落盘了，因为该函数是同步的。对于这种情况，就是耗性能，高性能和强一致性可能某种程度上是矛盾的，所以数据库的事务优化确实是很大一个研究领域。后面也会反复提到fsync这个函数。
内存映射文件与Zero Copy
相比于Direct IO，内存映射文件往前更进了一步，它是直接用应用程序的用户态内存映射到Linux内核缓冲区，应用程序读写自己的用户态内存相当于直接读写内核缓冲区。
内存映射文件的读写经过：应用程序内存（内核缓冲区） -> 磁盘，仅仅只有一次拷贝，性能更高。
熟悉Linux API就知道，mmap函数就是内存映射文件的API了，windows也有对应的API（CreateFileMapping， MapViewOfFile）。Java跨平台，封装了两种类型的API，提供一个更高层次的内存映射文件API叫MappedByteBuffer，底层原理都差不多。
Zero Copy又是提升IO性能的一个技术，Kafka在消费消息的时候就利用了Zero Copy技术。我们来看看最普通的，利用Direct IO实现的传输文件的网络发送代码:
以上代码总共发生了4次拷贝： 磁盘->内核缓冲区->应用程序内存buffer -> Socket buffer -> 网络
利用内存映射文件实现的同功能的代码:
以上代码总共发生了3次拷贝： 磁盘 -> 应用程序内存buffer(内核缓冲区) -> Socket buffer -> 网络
但是，如果引用Zero Copy技术，内核缓冲区到Socket缓冲区的拷贝也可以省略了，也就是数据拷贝不会发生在用户态内存了。因为内核缓冲区与Socket buffer建立了映射（由DMA模块办到），没有用户态的事情了，直接减小用户态到内核态的开销切换，所以叫零拷贝。
过程是这样的: 磁盘 -> 内核缓冲区（Socket buffer） -> 网络
Linux上Zero Copy的API是sendfile，Java对应的是FileChannel.transferTo。
看API的名字就是知道，Zero Copy几乎是为实现网络上高性能传输文件而设计的。
还想性能再高？那请关注DPDK,腾讯开源的F-stack就用了这种技术。
网络IO模型
之前写的服务端高性能网络编程的文章有提到过。但是都特别简单，这次会稍微深入点。
之前的文章，总结起来就是，阻塞和非阻塞，函数是否立即返回。同步异步，读写是否由操作系统完成。下面讲点详细的。
Linux的read，write函数，在调用的时候被阻塞，直到数据读写完成
也是read write函数，只是打开方式不同，打开文件描述符的时候带有O_NONBLOCK参数。于是，即使函数没有读写完成数据也会立即返回，不会阻塞，程序员需要编写代码主动去不断地轮询。
前面两种IO都只能用于简单的客户端开发，但是对于高性能服务端编程就需要处理很多的文件描述符。同步阻塞IO，每个线程只能处理一个文件描述符。同步非阻塞IO，要应用程序轮询大规模的文件描述符集合，不可行。所以就有了IO多路复用，一个线程能处理大规模的文件描述符集合。
Linux上有三种IO多路复用API：select，poll，epoll。其中epoll性能最高，主流都选择epoll。这三个API都是同步阻塞的。Java的NIO在Linux上就是基于poll或epoll的，有个selector来选择。
目前只有windows下的IOCP完善成熟，Linux下也有aio，但是不成熟，不考虑。异步IO的接口几乎完全异步化。
所以当我们提及IO模型的时候，一般认为是操作系统层面的，但是谈及具体框架的IO模型，可能是框架封装出来的IO概念，例如boost.asio Java Netty。说白了，Java NIO就是poll epoll IOCP在JVM层面提供的一个语言级的统一接口，Netty框架又是基于NIO来做的。得看以后技术发展，Netty框架的异步IO概念底层实现可能是同步，也可能是真正的异步。
Reactor和Proactor模式
请看：https://github.com/AlexiaChen/AlexiaChen.github.io/issues/79
上面讲的比较详细了。
select，epoll的LT和ET
函数声明我就不具体写了，具体用法是，传入readfds和writefds这两个bit数组，函数返回的时候，readfds和writefds的bit位会发生变化，以此来告知那个文件描述符上有事件，需要遍历数组，然后调用相应的read或write。大致就那么个思想。
跟select思想上差不多。不过多研究。
设计了一个逻辑上的epfd，epfd是个数字，把fd数组关联到上面，然后每次向内核传递的是epfd这个数字。
整个epoll过程分为以下三个步骤：
LT（水平触发，条件触发），读缓冲区只要不为空，就会一直触发读事件；写缓冲区只要不满，就会一直触发写事件
ET（边缘触发，状态触发），读缓冲区的状态从空转到非空的时候触发一次读事件；写缓冲区的状态从满转为非满的时候触发一次写事件。
从上面可以看到，ET模式实际做的事情应该会更少，并且一次到位，LT反而重复做了同样的事情，按理来说，ET性能会更高？但是实际上在工程中，大家一般用LT模式，这也是epoll的默认模式，Java的NIO用的也是LT模式。因为LT模式编写难度更高，容易遗漏事件，一次触发没处理好，不会给第二次机会了。
LT模式下因为写满缓冲区的概率很小，所以写完数据，记得取消注册的写事件。ET模式下，一旦读缓冲区有数据，记得一定把数据一次性读完，让缓冲区清空到空状态，不然就漏事件了。
根据陈硕说，目前没有任何实践证明ET性能比LT高，然后LT模式也更稳更安全些，所以大部分实践中都是默认LT模式了。
服务端编程的模型
一个监听线程，负责accept事件的注册和处理，和每个新进来的客户端建立socket连接，然后把socket连接交给IO线程，完成任务，继续监听新的客户端
N个IO线程，N一般等于CPU核数，负责每个socket连接上面read，write事件的注册和实际的socket的读写。把读到的Request放入Request队列，交由Workder线程异步处理
M个Worker线程，M的数量由具体业务决定，纯粹的业务线程，没有socket读写操作，对Request队列进行处理消费，生成Response队列，然后写入Response队列，交由IO线程处理，IO线程再回写数据给客户端。
大部分的服务端框架或服务器代码实现思路跟这个都差不多，大同小异。Tomcat6的NIO模块思路就是大致如此。