NGINX怎样处理惊群的
写在前面
写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_use_accept_mutex配置nginx是否利用ngx_accept_mutex锁的方式解决惊群问题(nginx只有这种方式,如果不使用,惊群问题就会存在),默认配置是打开的。
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具体什么时候会用到)。