水平触发和边缘触发
上面说到了 epoll，主要讲解了 client 端怎么连进来，但是并未详细的讲解 epoll_wait 怎么被唤醒的，这里我将来详细的讲解一下。
水平触发，意即 Level Trigger，边缘触发，意即 Edge Trigger，如果单从字面意思上理解，则不太容易，但是如果将硬件设计中的水平沿，上升沿，下降沿的概念引进来，则理解起来就容易多了。
比如我们可以这样认为：
如果将上图中的方块看做是 buffer 的话，那么理解起来则就更加容易了，比如针对水平触发，buffer 只要是一直有数据，则一直通知；而边缘触发，则 buffer 容量发生变化的时候，才会通知。
虽然可以这样简单的理解，但是实际上，其细节处理部分，比图示中展现的更加精细，这里来详细的说一下。
①边缘触发
针对读操作，也就是当前 fd 处于 EPOLLIN 模式下，即可读。此时意味着有新的数据到来，接收缓冲区可读，以下 buffer 都指接收缓冲区：
buffer 由空变为非空，意即有数据进来的时候，此过程会触发通知：
buffer 原本有些数据，这时候又有新数据进来的时候，数据变多，此过程会触发通知：
buffer 中有数据，此时用户对操作的 fd 注册 EPOLL_CTL_MOD 事件的时候，会触发通知：
针对写操作，也就是当前 fd 处于 EPOLLOUT 模式下，即可写。此时意味着缓冲区可以写了，以下 buffer 都指发送缓冲区：
buffer 满了，这时候发送出去一些数据，数据变少，此过程会触发通知：
buffer 原本有些数据，这时候又发送出去一些数据，数据变少，此过程会触发通知：
这里就是 ET 这种模式触发的几种情形，可以看出，基本上都是围绕着接收缓冲区或者发送缓冲区的状态变化来进行的。
晦涩难懂？不存在的，举个栗子：
在服务端，我们开启边缘触发模式，然后将 buffer size 设为 10 个字节，来看看具体的表现形式。
服务端开启，客户端连接，发送单字符 A 到服务端，输出结果如下：
-->ET Mode: it was triggered once get 1 bytes of content: A -->wait to read!
可以看到，由于 buffer 从空到非空，边缘触发通知产生，之后在 epoll_wait 处阻塞，继续等待后续事件。
这里我们变一下，输入 ABCDEFGHIJKLMNOPQ，可以看到，客户端发送的字符长度超过了服务端 buffer size，那么输出结果将是怎么样的呢？
-->ET Mode: it was triggered once get 9 bytes of content: ABCDEFGHI get 8 bytes of content: JKLMNOPQ -->wait to read!
可以看到，这次发送，由于发送的长度大于 buffer size，所以内容被折成两段进行接收，由于用了边缘触发方式，buffer 的情况是从空到非空，所以只会产生一次通知。
②水平触发
水平触发则简单多了，他包含了边缘触发的所有场景，简而言之如下：
当接收缓冲区不为空的时候，有数据可读，则读事件会一直触发：
当发送缓冲区未满的时候，可以继续写入数据，则写事件一直会触发：
同样的，为了使表达更清晰，我们也来举个栗子，按照上述入输入方式来进行。
服务端开启，客户端连接并发送单字符 A，可以看到服务端输出情况如下：
-->LT Mode: it was triggered once! get 1 bytes of content: A
这个输出结果，毋庸置疑，由于 buffer 中有数据，所以水平模式触发，输出了结果。
服务端开启，客户端连接并发送 ABCDEFGHIJKLMNOPQ，可以看到服务端输出情况如下：
-->LT Mode: it was triggered once! get 9 bytes of content: ABCDEFGHI -->LT Mode: it was triggered once! get 8 bytes of content: JKLMNOPQ
从结果中，可以看出，由于 buffer 中数据读取完毕后，还有未读完的数据，所以水平模式会一直触发，这也是为啥这里水平模式被触发了两次的原因。
有了这两个栗子的比对，不知道聪明的你，get 到二者的区别了吗？
在实际开发过程中，实际上 LT 更易用一些，毕竟系统帮助我们做了大部分校验通知工作，之前提到的 SELECT 和 POLL，默认采用的也都是这个。
但是需要注意的是，当有成千上万个客户端连接上来开始进行数据发送，由于 LT 的特性，内核会频繁的处理通知操作，导致其相对于 ET 来说，比较的耗费系统资源，所以，随着客户端的增多，其性能也就越差。
而边缘触发，由于监控的是 FD 的状态变化，所以整体的系统通知并没有那么频繁，高并发下整体的性能表现也要好很多。
但是由于此模式下，用户需要积极的处理好每一笔数据，带来的维护代价也是相当大的，稍微不注意就有可能出错。所以使用起来须要非常小心才行。
至于二者如何抉择，诸位就仁者见仁智者见智吧。
行文到这里，关于 epoll 的讲解基本上完毕了，大家从中是不是学到了很多干货呢？
由于从 Netty 研究到 linux epoll 底层，其难度非常大，可以用曲高和寡来形容，所以在这块探索的文章是比较少的，很多东西需要自己照着 man 文档和源码一点一点的琢磨（linux 源码详见 eventpoll.c 等）。
这里我来纠正一下搜索引擎上，说 epoll 高性能是因为利用 mmap 技术实现了用户态和内核态的内存共享，所以性能好。
我前期被这个观点误导了好久，后来下来了 Linux 源码，翻了一下，并没有在 epoll 中翻到 mmap 的技术点，所以这个观点是错误的。
这些错误观点的文章，国内不少，国外也不少，希望大家能审慎抉择，避免被错误带偏。
所以，epoll 高性能的根本就是，其高效的文件描述符处理方式加上颇具特性边的缘触发处理模式，以极少的内核态和用户态的切换，实现了真正意义上的高并发。
手写 epoll 服务端
实践是最好的老师，我们现在已经知道了 epoll 之剑怎么嵌入到石头中的，现在就让我们不妨尝试着拔一下看看。
手写 epoll 服务器，具体细节如下（非 C 语言 coder，代码有参考）：
#include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <stdlib.h> #include <sys/epoll.h> #include <pthread.h> #include <errno.h> #include <stdbool.h> #define MAX_EVENT_NUMBER 1024 //事件总数量 #define BUFFER_SIZE 10 //缓冲区大小，这里为10个字节 #define ENABLE_ET 0 //ET模式 /* 文件描述符设为非阻塞状态 * 注意：这个设置很重要，否则体现不出高性能 */ int SetNonblocking(int fd) { int old_option = fcntl(fd, F_GETFL); int new_option = old_option | O_NONBLOCK; fcntl(fd, F_SETFL, new_option); return old_option; } /* 将文件描述符fd放入到内核中的epoll数据结构中并将fd设置为EPOLLIN可读，同时根据ET开关来决定使用水平触发还是边缘触发模式 * 注意：默认为水平触发，或上EPOLLET则为边缘触发 */ void AddFd(int epoll_fd, int fd, bool enable_et) { struct epoll_event event; //为当前fd设置事件 event.data.fd = fd; //指向当前fd event.events = EPOLLIN; //使得fd可读 if(enable_et) { event.events |= EPOLLET; //设置为边缘触发 } epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &event); //将fd添加到内核中的epoll实例中 SetNonblocking(fd); //设为非阻塞模式 } /* LT水平触发 * 注意：水平触发简单易用，性能不高，适合低并发场合 * 一旦缓冲区有数据，则会重复不停的进行通知，直至缓冲区数据读写完毕 */ void lt_process(struct epoll_event* events, int number, int epoll_fd, int listen_fd) { char buf[BUFFER_SIZE]; int i; for(i = 0; i < number; i++) //已经就绪的事件，这些时间可读或者可写 { int sockfd = events[i].data.fd; //获取描述符 if(sockfd == listen_fd) //如果监听类型的描述符，则代表有新的client接入，则将其添加到内核中的epoll结构中 { struct sockaddr_in client_address; socklen_t client_addrlength = sizeof(client_address); int connfd = accept(listen_fd, (struct sockaddr*)&client_address, &client_addrlength); //创建连接并返回文件描述符（实际进行的三次握手过程） AddFd(epoll_fd, connfd, false); //添加到epoll结构中并初始化为LT模式 } else if(events[i].events & EPOLLIN) //如果客户端有数据过来 { printf("-->LT Mode: it was triggered once!\n"); memset(buf, 0, BUFFER_SIZE); int ret = recv(sockfd, buf, BUFFER_SIZE - 1, 0); if(ret <= 0) //读取数据完毕后，关闭当前描述符 { close(sockfd); continue; } printf("get %d bytes of content: %s\n", ret, buf); } else { printf("something unexpected happened!\n"); } } } /* ET Work mode features: efficient but potentially dangerous */ /* ET边缘触发 * 注意：边缘触发由于内核不会频繁通知，所以高效，适合高并发场合，但是处理不当将会导致严重事故 其通知机制和触发方式参见之前讲解，由于不会重复触发，所以需要处理好缓冲区中的数据，避免脏读脏写或者数据丢失等 */ void et_process(struct epoll_event* events, int number, int epoll_fd, int listen_fd) { char buf[BUFFER_SIZE]; int i; for(i = 0; i < number; i++) { int sockfd = events[i].data.fd; if(sockfd == listen_fd) //如果有新客户端请求过来，将其添加到内核中的epoll结构中并默认置为ET模式 { struct sockaddr_in client_address; socklen_t client_addrlength = sizeof(client_address); int connfd = accept(listen_fd, (struct sockaddr*)&client_address, &client_addrlength); AddFd(epoll_fd, connfd, true); } else if(events[i].events & EPOLLIN) //如果客户端有数据过来 { printf("-->ET Mode: it was triggered once\n"); while(1) //循环等待 { memset(buf, 0, BUFFER_SIZE); int ret = recv(sockfd, buf, BUFFER_SIZE - 1, 0); if(ret < 0) { if(errno == EAGAIN || errno == EWOULDBLOCK) //通过EAGAIN检测，确认数据读取完毕 { printf("-->wait to read!\n"); break; } close(sockfd); break; } else if(ret == 0) //数据读取完毕，关闭描述符 { close(sockfd); } else //数据未读取完毕，继续读取 { printf("get %d bytes of content: %s\n", ret, buf); } } } else { printf("something unexpected happened!\n"); } } } int main(int argc, char* argv[]) { const char* ip = "10.0.76.135"; int port = 9999; //套接字设置这块，参见https://www.gta.ufrj.br/ensino/eel878/sockets/sockaddr_inman.html int ret = -1; struct sockaddr_in address; bzero(&address, sizeof(address)); address.sin_family = AF_INET; inet_pton(AF_INET, ip, &address.sin_addr); address.sin_port = htons(port); int listen_fd = socket(PF_INET, SOCK_STREAM, 0); //创建套接字并返回描述符 if(listen_fd < 0) { printf("fail to create socket!\n"); return -1; } ret = bind(listen_fd, (struct sockaddr*)&address, sizeof(address)); //绑定本机 if(ret == -1) { printf("fail to bind socket!\n"); return -1; } ret = listen(listen_fd, 5); //在端口上监听 if(ret == -1) { printf("fail to listen socket!\n"); return -1; } struct epoll_event events[MAX_EVENT_NUMBER]; int epoll_fd = epoll_create(5); //在内核中创建epoll实例，flag为5只是为了分配空间用，实际可以不用带 if(epoll_fd == -1) { printf("fail to create epoll!\n"); return -1; } AddFd(epoll_fd, listen_fd, true); //添加文件描述符到epoll对象中 while(1) { int ret = epoll_wait(epoll_fd, events, MAX_EVENT_NUMBER, -1); //拿出就绪的文件描述符并进行处理 if(ret < 0) { printf("epoll failure!\n"); break; } if(ENABLE_ET) //ET处理方式 { et_process(events, ret, epoll_fd, listen_fd); } else //LT处理方式 { lt_process(events, ret, epoll_fd, listen_fd); } } close(listen_fd); //退出监听 return 0; }
详细的注释我都已经写上去了，这就是整个 epoll server 端全部源码了，仅仅只有 200 行左右，是不是很惊讶。
接下来让我们来测试下性能，看看能够达到我们所说的单机百万并发吗？其实悄悄的给你说，Netty 底层的 C 语言实现，和这个是差不多的。
单机百万并发实战
在实际测试过程中，由于要实现高并发，那么肯定得使用 ET 模式了。
但是由于这块内容更多的是 Linux 配置的调整，且前人已经有了具体的文章了，所以这里就不做过多的解释了。
这里我们主要是利用 VMware 虚拟机一主三从，参数调优，来实现百万并发。
此块内容由于比较复杂，先暂时放一放，后续将会搭建环境并对此手写 server 进行压测。
