nginx与epoll

要了解Nginx中epoll的应用，首先要了解nginx的请求处理机制

为了响应客户端或者对端服务器的请求，服务器一般需要拥有并行或者并发能力，即同时或者同时段可以响应客户端的请求，一般的做法有：

多进程的方式，缺点是进程数量过多的时候，内存等系统资源开销过大，可能会导致系统奔溃。

多线程的方式，缺点是线程间共享内存，得考虑线程安全的问题，还得考虑锁的问题。

nginx 的进程模型选择的是多进程+异步非阻塞（epoll）

多进程 指 一个master进程+多个worker进程（可配置，一般为内核数）+ cache manager进程+cache loader进程

异步非阻塞 指worker进程的事件驱动模型采用的是epoll事件驱动库（多路io复用）的方式来和客户端交互。

master进程作用

worker 任务

cache loader

master 和worker 通信

worker 之间通信

worker 的异步非阻塞

异步非阻塞的事件处理机制也称为事件驱动模型有哪些

1轮询
2通知

衍生出事件驱动库也就是我们经常听的多路io复用

是select\poll\epoll、kqueue

本质： 单个进程监控多个文件描述符FD,一旦某个FD可读或者可写，则通知相应的进程进行读写 *** 作

从网卡接收数据说起,需要明白的几个知识点

#2022有你相伴#

了解IO多路复用应该对epoll和select不陌生吧。

首先，select是有缺陷的，就是当事件发生(调用select）的时候，都需要在用户态和内核态之间拷贝fd数组，要知道用户态和内核态之间进行内存的拷贝是非常昂贵的，如果有上万级别的并发网络需要处理的时候，服务器根本处理不来。

这时候，Linux内核的开发者应该算是简单又粗暴的增加了一个内核调用，就是epoll了，有时候简单粗暴的东西还是能提高效率的。

先来看select接口 ：

select是用来等待fd状态的改变，核心就是定义一组fds，如果fds中的某一个fd的状态改变（比如变得可读、可写、或者异常等），select就会从等待中返回。

可以理解为这个东西必须要靠一个fd的改变才能让系统调用去等待，先别思维跳跃，我们一步一步的分析下去，它的手段我觉得肯定是让这个系统调用等在一个等待队列wait_queue上，在不需要执行任务的时候，我们就让任务进程休眠，直到条件改变时，我们再唤醒它。

通俗的说就是：你是餐饮店里唯一的一个的服务员，当店里没有顾客或者有顾客但是没有请求的时候，你处于空闲状态，就可以做点自己的事情(比如玩玩手机），当有顾客来有需求的时候你再过去服务。

如果店里来了10个顾客，有10个顾客(10个fd)都需要监控处理，哪个顾客有请求就要立即去处理，我们先抛开内核是怎么实现的，这时候能想到有两种办法：

招10个服务员对老板来说是需要成本的，所以创建10个线程也是需要成本的。

如果你有两个核，那么创建10个线程毫无意义，大家都知道线程是有时间片的，如果某一个fd的改变去处理只处理到一半，这时候这个线程的时间片用完了，就会切换到另一个线程执行，这个切换不仅增加了成本，而且毫无意义。

还不如只创建两个线程，每个线程只处理一组fds中的一半，处理完一个请求，再去处理另一个请求。不过如果是在用户态是做不了这件事的，只有调度器去搞定。这样你就只能等待在多个fd上，哪个fd请求，就去处理哪一个，处理完再去看看有没有下一个fd需要请求。

然而，如果随着fd的数量的不断增加，效率就会变得越来越低。

总之，对于select，应该没有什么好办法了，应该只能做到这样了，如果你觉得可能某一天，select实现了更高效的算法呢？

我觉得应该不会的，select接口已经那样了。我们只能接受select这个接口的缺陷，明明知道会带来限制，我们就知道去规避这个缺陷，知道什么情况下使用它。

再来看看epoll接口：

从接口看，和select接口几乎差不多的，区别主要是select主要是线性遍历fd数组去找就绪的fd，而epoll是把就绪的fd（epollfd）放在一个链表里，不需要遍历全部fd，这样就减少了不少开销。

我们来简单想一下：把原来select的大部分接口封装在epoll上，其实不是很难，epoll需要调用epoll_create创建epollfd，那么我们改成select自动创建epollfd，然后调用epoll_ctl把数组的fds设置进去，然后调用epoll_wait就可以了。

当然我只是简单想一下而已，初衷是想告诉大家：

再从内核的角度我们简单想一下：一开始应该会想到epoll和select应该是复用同一个内核的吧。实际上，它们都是独立的，一个在fs/selectc中实现，一个在fs/eventpollc中实现。

整体来看，select和epoll本质是一个东西，epoll有一个比较明显的改进是增加了两个对文件描述符的 *** 作的模式： 水平触发 (LT:level trigger）和 边缘触发 (ET:edge trigger）。

现在，对于select和epoll就会形成一种理解： epoll是对select的升级，在fds比较多的情况下，优先考虑使用epoll。

当我们分析epoll和select的时候，我们不能直接跳跃到内核看是怎么实现的，应该看它的整个逻辑来分析，脑子里要形成一些疑问，就比如select已经存在的缺陷是什么？但是又有什么好处？epoll为什么改进？改进了是不更好了？还有没有值得优化的地方？通过整个分析理解下来就能更加了解epoll和select。

你也可以继续阅读 点击 以下文章，下面是我推荐给大家的几篇文章：

1《竟然把通信协议讲的如此通俗？》

2《彻底明白Linux硬链接和软链接》

3《浅析Makefile、make、cmake》

4《常见硬件通信(SPI、I2C、CAN、USB、UART)协议介绍》

---