走进nginx事件驱动模型

### 简单论述nginx的epoll模型 本文只以epoll为例 nginx以epoll为事件驱动的基础，epoll共检测4类事件，分别如下 - 处理新连接事件 - 处理定时事件 - 处理普通读写事件 - 处理从磁盘读事件 ### (1)处理新连接事件 首先来谈第一个处理新连接事件，我们在平时的服务器设计时，由于连接事件比较敏感(对快速响应要求比较高)，所以我会单开一个线程(进程)来专门处理连接，获取连接后然后在分发给各个I/O复用线程，然而nginx的处理连接事件和处理其他事件都是在同一个I/O复用下，那么它是如何保证连接事件对响应的要求的呢？niginx是通过将获取的事件先不调用其回调，而是把他们先放入俩个post队列，这俩个队列分别为 - ngx_posted_accept_events - ngx_posted_events 第一个队列用来保存连接事件，而第二个队列用来保存普通读写事件，之后在执行时我们可以先保证ngx_posted_accept_events中的事件先处理，就可以保证连接对响应速度的敏感性 ### (2)如何防止串话 串话问题可以说是服务器程序中都需要处理的一个问题。串话问题是指刚刚关闭了一个套接字，又来了一个新连接，而新连接刚好系统给分配的就是刚关闭的那个套接字，那么如果方才哪个套接字还有事件未处理完成，接下来它给对应的套接字发送数据很有可能就会发到新建立的用户那。那么nginx如何来解决这个问题呢？ 很简单，nginx在每次获得新连接后都会将连接中的一个标志为置反，这样本个连接和上个连接的instance就会不同，而每个事件都包含了连接，所以每次处理事件时只需要比较事件中的instance是否相同就OK了 ### (3)如何处理”惊群问题” 所谓惊群问题就是说多个进程在同时监听同一个端口，当有连接到来时，系统会把多个进程都唤醒，但是当然任然只有一个进程能处理到新连接，所以本来其他进程是不需要被唤醒的，但是被唤醒了，这就是注明的惊群问题。 nginx解决它的方法也很简单，只需要保证同一时间点只有一个进程在监听端口就可避免惊群问题了。但是问题的关键是如何能保证同一时间点只有一个进程来监听端口。nginx采用了尝试加锁，根据加锁的返回值确定本进程是否要接下来处理新连接事件，从而解决了”惊群问题” ### (4)如何解决负载均衡 在我之前写的一个小网络库中，我所采用的负载均衡很简单，就是主线程用来接受新连接，然后轮流把新连接分发给各个子线程，而nginx解决个进程间的负载均衡问题并没有均衡分配，而是当每个进程处理的额连接数超过了规定其处理的最大连接数的7/8时，就会本次不处理连接，而是将其处理的连接数-1，这样相当于就把机会让给了其他线程，从而实现了负载均衡了