epoll

… … #核心摸块 events { #事件模块 … } http { # http 模块 server { # server块 location [PATTERN] { # location块 … } location [PATTERN] { … } } server { … } } mail { # mail 模块 server { # server块 … } } 我们依次看一下每个模块一般有哪些配置项。 核心模块 user admin; #配置用户或者组 worker_processes 4; #允许生成的进程数，默认为1 pid /nginx/pid/nginx.pid; #指定 nginx 进程运行文件存放地址 error_log log/error.log debug; #错误日志路径，级别 事件模块 events { accept_mutex on; #设置网路连接序列化，防止惊群现象发生，默认为on multi_accept on; #设置一个进程是否同时接受多个网络连接，默认为off use epoll; #事件驱动模型select|poll|kqueue|epoll|resig worker_connections 1024; #最大连接数，默认为512 } http 模块 http { include mime.types; #文件扩展名与文件类型映射表

一. nginx基本介绍 Nginx特性： Nginx (engine x) 是一个高性能的HTTP和反向代理服务，也是一个IMAP/POP3/SMTP服务。Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好。 1、nginx高并发原理（ 多进程+epoll实现高并发 ） Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。 每个子进程只有一个线程，采用的 IO多路复用模型epoll，实现高并发。 2、epoll能实现高并发原理 epoll() 中内核则维护一个链表，epoll_wait 方法可以获取到链表长度，不为0就知道文件描述符准备好了。 在内核实现中 epoll 是根据每个 sockfd 上面的与设备驱动程序建立起来的回调函数实现的。 某个 sockfd 上的事件发生时，与它对应的回调函数就会被调用，来把这个 sockfd 加入链表，其他处于“空闲的”状态的则不会。 epoll上面链表中获取文件描述，这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销 内存映射（mmap）：内存映射文件，是由一个文件到一块内存的映射，将不必再对文件执行I/O操作

在 nginx基于epoll模型事件驱动流程详解 中我们讲到，epoll在触发accept事件之后，会回调 ngx_event_accept() 方法。这个方法主要做了两件事： 获取accept到的客户端连接句柄，并且初始化一个 ngx_connection_t 结构体，用以表征这个连接； 检查新的连接是否存在可以读取的数据，如果有，则读取并处理数据，否则将当前连接句柄添加到epoll框架中，以监听其可读事件。 上面的第一个步骤在 nginx基于epoll模型事件驱动流程详解 已经做了详细讲解，这里我们主要讲解第二个步骤是如何实现的。在 ngx_event_accept() 方法的最后，其会调用如下一段代码： void ngx_event_accept(ngx_event_t *ev) { do { // 省略... // 建立新连接之后的回调方法，这个方法是在ngx_http_block()方法中解析http配置块的最后 // ngx_http_optimize_servers()方法中进行初始化的，其指向的是ngx_http_init_connection()方法 ls->handler(c); // 省略... } while (ev->available); } 这里的 ls->handler() 方法指向的是 ngx_http_init_connection()

概念理解 selector与epoll是多路复用的函数。我认为多路复用是针对bio而言，指的是通过单线程来追踪管理多个socket对象。传统的bio中，在socket的accept与read两个阶段都会造成阻塞，那么就无法处理并发问题，即仅一个socket对象就已经占用了IO对象，没有余力解决其他线程的请求。那么如何让bio能够处理并发问题呢？就是在accept和read阶段不再阻塞，当accept到socket对象的时候就将其缓存至list中，同时如果read到数据了就处理数据。但如果没有accept对象，则会去list中询问以前accept的对象有没有需要read的数据。如此，通过一个线程完成了多个socket对象的管理。那么selector与epoll就是完成了上述功能。 对比分析 selector内部维持了一个数据结构（bitmap），用来存储已经接受的socket对象。然后将此数据复制一份，交给内核去轮训每个socket对象是否有期待的事件发生，如果有就会进行置位（用户态到内核态的复制）。然后返回给用户态，由用户态完成事件的处理。 epoll针对selector进行了优化，采用红黑树来存储accept的socket对象，同时还维持着一个list，存放有发生的事件的socket以及事件，然后将此任务队列返回。用户态无需遍历所有的socket对象。下图即为epoll的说明图。

TCP中出现的错误及处理 首先要明确，TCP连接关闭有两种方法其一是正常的四次挥手，会经历多个状态，最后连接正常关闭，还有一种方法是连接异常关闭，即此时对方希望连接能够尽快关闭，发送RST包后连接会直接关闭，不会再出现上述的状态转换 进程正常关闭/进程被杀死/服务器重启 这三种情况下，服务器关闭套接字，并发起第一次挥手操作，客户端收到FIN包，并返回ack， 此时连接处于半关闭状态，客户端并不知道服务器已经关闭，客户端如果继续向服务器write数据，那么服务器会向客户端发送RST包， 当客户端收到RST包时，如果再write，那么将返回EPIPE错误，同时会导致SIGPIPE信号，如果从收到RST包的连接上read，那么将返回ECONNRESET错误 如果客户端是使用的select/epoll等，那么当select/epoll收到RST会返回连接可读，即调用read返回ECONNRESET错误（但是 根据muduo库测试最后epoll收到RST后返回可读，但是read会返回0，此处存疑 ），注意这里所说的错误是errno的值，同时也是套接字的待处理错误，所以此时调用getsockopt所获得的error是相应的错误，epoll/select所监视的某个socket上如果出现了错误，那么将会返回可读可写 服务器崩溃/服务器不可达 服务器崩溃时，如果有数据发送，那么TCP会重传数据

水平触发模式-根据读来解释 只要fd对应的缓冲区有数据 epoll_wait返回 返回的次数与发送数据的次数没有关系 epoll默认的工作模式 边沿触发模式 - ET fd - 默认阻塞属性 客户端给server发数据: 发一次数据server 的 epoll_wait返回一次  不在乎数据是否读完  如果读不完, 如何全部读出来? while(recv()); 数据读完之后recv会阻塞 解决阻塞问题 设置非阻塞 - fd 边沿非阻塞触发 效率最高 如何设置非阻塞 open() □ 设置flags □ 必须 O_WDRW | O_NONBLOCK □ 终端文件: /dev/tty fcntl() □ int flag = fcntl(fd, F_GETFL); □ flag |= O_NONBLOCK; □ fcntl(fd, F_SETFL, flag); 将缓冲区的全部数据都读出 while(recv() > 0) {printf(): } epoll_wait 调用次数越多, 系统的开销越大 水平触发模式 #include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <sys/types.h> #include <string.h> #include <sys/socket.h> #include

惊群 所谓惊群即：多个进程/线程同时阻塞等待同一个事件的发生，如果这个事件发生，那么会唤醒所有进程/线程，但是却只有一个进程/线程会对该事件进行处理，那么其他唤醒的进程/线程会继续休眠阻塞，从而造成性能浪费，这种现象即为惊群。 accept惊群 最常见的即，服务器进程在listen后fork出多个子进程来阻塞accept客户端发起连接，当客户端发起连接时，所有子进程将被唤醒，但是实际上只有一个进程可以获取该连接，而其他进程继续阻塞， 不过新版的linux已经解决了这个问题，即唤醒最先阻塞的进程来获取该连接 epoll惊群 第一种情况是在fork之前创建epollfd，然后主进程fork多个子进程，每个子进程将listenfd加入到epollfd中，当一个连接到来会触发epoll惊群，多个子进程的epoll会被同时触发。造成惊群，不过新版的epoll已经解决了此问题 第二种情况是主进程创建listenfd，主进程创建多个子进程，同时每个子进程有自己的epollfd，每个子进程将listenfd加入到epollfd中，这样当一个连接到来时，会触发惊群，有待解决。NGINX中使用互斥锁和主动的方式去解决惊群问题解决了该惊群问题 nginx解决惊群问题的方法是在每次循环到epoll_wait时，几个子进程竞争互斥锁，获得互斥锁的子进程则将监听fd加到epoll中

1 性能测试 测试环境： RHEL 6.3 / HP Gen8 Server/ 2 * Intel Xeon 2.00GHz(6 core) / 64G DDR3 memory / 300G RAID-1 SATA / 1 master(writ AOF), 1 slave(write AOF & RDB) 数据准备： 预加载两千万条数据，占用10G内存。 测试工具：自带的redis-benchmark，默认只是基于一个很小的数据集进行测试，调整命令行参数如下，就可以开100条线程(默认50)，SET 1千万次(key在0-1千万间随机)，key长21字节，value长256字节的数据。 1 redis-benchmark -t SET -c 100 -n 10000000 -r 10000000 -d 256 测试结果(QPS)： 1.SET：4.5万， 2.GET：6万 ， 3.INCR：6万， 4.真实混合场景: 2.5万SET & 3万GET 单条客户端线程时6千TPS，50与100条客户端线程差别不大，200条时会略多。 Get/Set操作，经过了LAN，延时也只有1毫秒左右，可以反复放心调用，不用像调用REST接口和访问数据库那样，每多一次外部访问都心痛。 资源监控: 1.CPU: 占了一个处理器的100%，总CPU是4%(因为总共有2CPU 6核 超线程 =

1、nginx相对于apache的优点： 轻量级，同样起web 服务，比apache 占用更少的内存及资源 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 高度模块化的设计，编写模块相对简单 社区活跃，各种高性能模块出品迅速啊 apache 相对于nginx 的优点： rewrite ，比nginx 的rewrite 强大 模块超多，基本想到的都可以找到 少bug ，nginx 的bug 相对较多 超稳定 存在就是理由，一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。后者的各种功能模块实现得比前者，例如ssl 的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由，但并不是所有的情况下都是epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的select 模型或许比epoll 更高性能。当然，这只是根据网络IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。 2、作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下

目录 NIO-EPollSelectorIpml源码分析 目录 前言 初始化EPollSelectorProvider 创建EPollSelectorImpl EPollSelectorImpl结构 fdToKey 管道文件描述符 EPollArrayWrapper 注册 doSelect 关闭EpollSelectorImpl 总结 相关文献 NIO-EPollSelectorIpml源码分析 目录 NIO-概览 NIO-Buffer NIO-Channel NIO-Channel接口分析 NIO-SocketChannel源码分析 NIO-FileChannel源码分析 NIO-Selector源码分析 NIO-WindowsSelectorImpl源码分析 NIO-EPollSelectorIpml源码分析 前言 本来是想学习Netty的，但是Netty是一个NIO框架，因此在学习netty之前，还是先梳理一下NIO的知识。通过剖析 源码 理解NIO的设计原理。 本系列文章针对的是JDK1.8.0.161的源码。 NIO-Selector源码分析 对 Selector 的功能和创建过程进行了分析，本篇对Linux环境下JDK实现的 EPollSelectorImpl 源码进行详细讲解。 本篇文章不会对EPoll算法进行详细介绍，对epoll算法感兴趣或还不了解的同学可以看