写在前面
写NGINX系列的随笔，一来总结学到的东西，二来记录下疑惑的地方，在接下来的学习过程中去解决疑惑。
也希望同样对NGINX感兴趣的朋友能够解答我的疑惑，或者共同探讨研究。
整个NGINX系列的文章中，我会将我的疑惑用红色标出，希望能遇到前辈在评论中给我解答迷津。
----基于nginx 1.4.4
（虽然类似的文章博客已经很多了，但学了东西不整理记录，始终变不成自己的东西。）
所谓的惊群
简单举例来说
TCP服务端socket的建立，一般经过socket、bind、listen初始化后，调用accept等待客户端的连接。服务器一般做法会在listen后，fork多个子进程同时accept客户端的连接。
子进程在调用accept后会堵塞睡眠，当第一个客户端连接到来后，所有子进程都会唤醒，但只会有一个子进程accept调用成功，其他子进程返回失败，代码中的处理往往在accept返回失败后，继续调用accept。
虽然这在功能上没有什么问题，但在性能上很是浪费。有一种处理方式，是父进程调用accept之后，然后通过某种方式传递给子进程处理连接（怎么传递？我没想到，fork时，子进程会复制父进程的资源，因此子进程accept就是父进程初始化好的fd，但如果子进程fork后，父进程给子进程传递accept到的资源描述符fd，怎么传递？），但需要一个单独的进程处理accept，其实也是对CPU的一种浪费。
（问题补充：可以在accept后，fork子进程处理新连接）
惊群的解决
Linux内核2.6已经解决了accept时的惊群问题，多个子进程accept堵塞睡眠时，连接到来，只有一个进程的accept会被唤醒返回。但现在子进程的实现方式不是直接accept，而是将初始化好的fd加入到epoll 的事件队列中，epoll返回后再调用accept。Linux无法解决多个子进程epoll返回的情况。这需要子进程自己处理。
Nginx的处理
Nginx中处理epoll时惊群问题的思路很简单，多个子进程有一个锁，谁拿到锁，谁才将accept的fd加入到epoll队列中，其他的子进程拿不到锁，也就不会将fd加入到epoll中，连接到来也就不会导致所有子进程的epoll被唤醒返回。
。。。明天分析代码。
代码分析
Nginx执行路径
1 nginx.c:main() 2 ngx_master_process_cycle() 3 ngx_start_worker_processes() 4 ngx_spawn_process() 5 ngx_worker_process_cycle() 6 { 7 for(;;) { 8 ngx_process_events_and_timers() 9 } 10 }
惊群处理的代码
ngx_process_events_and_timers()处理事件，这个函数中的以下代码，处理惊群问题，顺带实现了负载均衡，因为处理惊群问题和负载均衡问题的代码在一起，下面一起分析一下。
1 if (ngx_use_accept_mutex) { 2 if (ngx_accept_disabled > 0) { 3 ngx_accept_disabled--; 4 5 } else { 6 if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { 7 return; 8 } 9 10 if (ngx_accept_mutex_held) { 11 flags |= NGX_POST_EVENTS; 12 13 } else { 14 if (timer == NGX_TIMER_INFINITE 15 || timer > ngx_accept_mutex_delay) 16 { 17 timer = ngx_accept_mutex_delay; 18 } 19 } 20 } 21 }
ngx_accept_disable用于处理负载均衡。
这里可以看出使用ngx_accept_mutex锁的情况下，一个进程要处理accept事件，必须满足两个条件：
- 满足负载均衡条件（负载压力低，稍后介绍nginx怎么判断压力高低）
- 获取ngx_accept_mutex锁
负载均衡条件
Ngx_accept_disable会在每次accept事件正确处理后，更新其值
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;
connection_n是配置文件中配置的该进程处理的最大连接数，free_connection_n初始值为connection_n，新建一个连接++，关闭一个连接--。
（我没有看到ngx_accept_disabled初始值是在哪赋值的，有时间调试一下，看看初始值是多少）
当free_connection_n 大于connection_n的1 / 8（连接数少于总数的7 / 8）时，ngx_accept_disable是负的，此时进程会参与锁的争夺，如果获得锁，该进程处理accept事件，其他进程，不处理accept事件。
当该进程处理accept事件增多，处理的连接也就增多，当free_connection_n小于connection_n的1 / 8（连接数大于总数的7 / 8）时，ngx_accept_disabled是正的，此时该进程会简单的将ngx_accept_disabled--，并退出锁的争夺，把机会让给其他进程。就这样平衡了负载，防止一个进程负载过高。
进程的连接越多，放弃争夺的次数也就越多，而ngx_accept_disabled--，避免了进程一直退出锁的争夺，防止不再接受新连接。
当每个进程的连接数都比较少时，谁抢到了ngx_accept_disable，谁处理连接；当一个进程抢的比较多，连接数率先达到了 7/ 8，那么就会退出锁的争夺，把机会让给其他进程，并不时ngx_accept_disabled--，保证一段时间后继续参加锁的争夺；当所有进程的连接数都大于 7 / 8时，这时再有新连接到来，处理延迟应该会比较大，因为所有进程都放弃了争夺，直到ngx_accept_disable—到小于0，再次争夺。
获取ngx_accept_mutex锁
当满足了负载均衡条件，进程就会参与ngx_accept_mutex锁的争夺 ngx_trylock_accept_mutex(cycle)
Ngx_trylock_accept_mutex出现错误，直接return了
没有错误的情况
ngx_accept_mutex_held=1表示拿到了锁
拿到锁会设置flags |= NGX_POST_EVENTS; 设置了这个标志，epoll返回的所有事件不会立即处理，而是将事件放到post队列中，然后释放锁后在把队列中的事件一一拿出处理，这样做的原因是防止处理事件导致锁长时间得不到释放，新的accept连接事件得不到（其他进程的）及时处理。
ngx_accept_mutex_held=0表示没有拿到锁
拿不到锁的进程会修改epoll超时时间，让epoll尽快返回，早早的参与到下一次锁的争夺上来，也就能快速的处理新的accept连接事件。
（写到这里不得不佩服作者真是各种情况都考虑到了，牛啊）
接下来看看关于锁的战争
1 ngx_int_t 2 ngx_trylock_accept_mutex(ngx_cycle_t *cycle) 3 { 4 if (ngx_shmtx_trylock(&ngx_accept_mutex)) { 5 if (ngx_accept_mutex_held 6 && ngx_accept_events == 0 7 && !(ngx_event_flags & NGX_USE_RTSIG_EVENT)) 8 { 9 return NGX_OK; 10 } 11 if (ngx_enable_accept_events(cycle) == NGX_ERROR) { 12 ngx_shmtx_unlock(&ngx_accept_mutex); 13 return NGX_ERROR; 14 } 15 ngx_accept_events = 0; 16 ngx_accept_mutex_held = 1; 17 18 return NGX_OK; 19 } 20 if (ngx_accept_mutex_held) { 21 if (ngx_disable_accept_events(cycle) == NGX_ERROR) { 22 return NGX_ERROR; 23 } 24 ngx_accept_mutex_held = 0; 25 } 26 return NGX_OK; 27 }
line4 试图获取锁
line20 没有获取到锁，但ngx_accept_mutex_held却是1，是个异常，禁止当前进程处理accept事件（将accept fd将epoll队列中移除），重置ngx_accept_mutex_held=0
line5-10 成功获取锁，发现自己早就获得了该锁，只是没有accept事件发生，又循环了一次，继续获得了该锁。（第一次没有事件发生，应该释放锁，再进入第二次的争夺呀？？）
line11-16 成功获得锁后，将accept fd加入到epoll队列中，准备监听accept事件，并置ngx_accept_mutex_head = 1表示获取到了锁（ngx_accept_events具体什么时候会用到）。