nginx事件模型小结

大家看到这篇文章可能会感觉很失望，居然没什么内容。。。写这篇的目的是给出一些我认为比较好的文章，做一下补充和概括。这里不写重复的内容，只是转发一下连接供大家参考。

1. http://www.tbdata.org/archives/1214

这是淘宝yixiao的分析文章，这篇给出了nginx事件抽象模型的基础构建，为事件循环的正是运作打基础。

2. http://www.tbdata.org/archives/1267

来自yixiao的第二篇事件分析文章，在1的基础上，分析了实际运作的事件处理循环。

这是一个抽象的模型，底层可能是epoll，kqueue等来具体驱动。

3. http://www.tbdata.org/archives/1296

来自yixiao的第三篇文章，这是一个linxu平台epoll来分析的，展示了抽象事件模型下的一种驱动。

BS: 网上关于epoll和nginx使用epoll的分析就很多了，大家可以自己找下。

这里先看下ngx_timer_resolution这个变量，大家想了解的话可以参考这篇博客：

http://lenky.info/2011/09/10/%E5%88%A9%E7%94%A8timer_resolution%E8%AE%BE%E7%BD%AE%E5%87%8F%E5%B0%91gettimeofday%E8%B0%83%E7%94%A8%E7%9A%84%E6%AC%A1%E6%95%B0/

一般情况下都是通过rb-tree来控制每次epoll_wait的超时时间，关于nginx红黑树的使用可以参考这个博客：http://blog.csdn.net/Lu_ming/article/details/5182577

强调几个关键点：

1. 防止惊群(有说法称，linux内核已经解决了这个问题，这个大家去考证了)

在多个进程同时监听的情况下，我们只能要做到某一时刻只要有一个进程可以accept，就可以防止惊群。为此，nginx使用ngx_accept_mutex，来做到进程间互斥，拿到这个锁的进程就有了accpet的资格。

2. accept负载均衡

由于多进程accept使用了互斥锁，可能此时有其他的进程也在等待accpet，要及时释放，给其它人机会。。。这方面nginx使用一个事件收集链，做到及时释放accept锁，然后自己慢慢处理事件。同时为了避免同一进程accept次数太多，负载过重，而其它进程可能空闲的情况，nginx使用了ngx_accept_disabled来控制一个进程的负载。对于没有能够accept成功的进程，就老老实实处理已经获得的事件吧，别吃着碗里的，看着锅里的。