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成功的进程,就老老实实处理已经获得的事件吧,别吃着碗里的,看着锅里的。。。