“惊群”，看看nginx是怎么解决它的

今天药忘吃喽~ 2022-06-16 11:55 161阅读 0赞

http://blog.csdn.net/russell\_tao/article/details/7204260

在说nginx前，先来看看什么是“惊群”？简单说来，多线程/多进程（[Linux][]下线程进程也没多大区别）等待同一个socket事件，当这个事件发生时，这些线程/进程被同时唤醒，就是惊群。可以想见，效率很低下，许多进程被内核重新调度唤醒，同时去响应这一个事件，当然只有一个进程能处理事件成功，其他的进程在处理该事件失败后重新休眠（也有其他选择）。这种性能浪费现象就是惊群。

惊群通常发生在server 上，当父进程绑定一个端口监听socket，然后fork出多个子进程，子进程们开始循环处理（比如accept）这个socket。每当用户发起一个TCP连接时，多个子进程同时被唤醒，然后其中一个子进程accept新连接成功，余者皆失败，重新休眠。

那么，我们不能只用一个进程去accept新连接么？然后通过消息队列等同步方式使其他子进程处理这些新建的连接，这样惊群不就避免了？没错，惊群是避免了，但是效率低下，因为这个进程只能用来accept连接。对多核机器来说，仅有一个进程去accept，这也是程序员在自己创造accept瓶颈。所以，我仍然坚持需要多进程处理accept事件。

其实，在linux2.6内核上，accept系统调用已经不存在惊群了（至少我在2.6.18内核版本上已经不存在）。大家可以写个简单的程序试下，在父进程中bind,listen，然后fork出子进程，所有的子进程都accept这个监听句柄。这样，当新连接过来时，大家会发现，仅有一个子进程返回新建的连接，其他子进程继续休眠在accept调用上，没有被唤醒。

但是很不幸，通常我们的程序没那么简单，不会愿意阻塞在accept调用上，我们还有许多其他网络读写事件要处理，linux下我们爱用epoll解决非阻塞socket。所以，即使accept调用没有惊群了，我们也还得处理惊群这事，因为epoll有这问题。上面说的[测试][Link 1]程序，如果我们在子进程内不是阻塞调用accept，而是用epoll\_wait，就会发现，新连接过来时，多个子进程都会在epoll\_wait后被唤醒！

nginx就是这样，master进程监听端口号（例如80），所有的nginx worker进程开始用epoll\_wait来处理新事件（linux下），如果不加任何保护，一个新连接来临时，会有多个worker进程在epoll\_wait后被唤醒，然后发现自己accept失败。现在，我们可以看看nginx是怎么处理这个惊群问题了。

nginx的每个worker进程在函数ngx\_process\_events\_and\_timers中处理事件，(void) ngx\_process\_events(cycle, timer, flags);封装了不同的事件处理机制，在linux上默认就封装了epoll\_wait调用。我们来看看ngx\_process\_events\_and\_timers为解决惊群做了什么：

**\[cpp\]** [view plain][] [copy][view plain]

1.  **void**
2.  ngx\_process\_events\_and\_timers(ngx\_cycle\_t \*cycle) 
3.  \{ 
4.  。。。 。。。 
5.  //ngx\_use\_accept\_mutex表示是否需要通过对accept加锁来解决惊群问题。当nginx worker进程数>1时且配置文件中打开accept\_mutex时，这个标志置为1
6.  **if** (ngx\_use\_accept\_mutex) \{ 
7.  //ngx\_accept\_disabled表示此时满负荷，没必要再处理新连接了，我们在nginx.conf曾经配置了每一个nginx worker进程能够处理的最大连接数，当达到最大数的7/8时，ngx\_accept\_disabled为正，说明本nginx worker进程非常繁忙，将不再去处理新连接，这也是个简单的负载均衡
8.  **if** (ngx\_accept\_disabled > 0) \{ 
9.   ngx\_accept\_disabled--; 
10. 
11.  \} **else** \{ 
12. //获得accept锁，多个worker仅有一个可以得到这把锁。获得锁不是阻塞过程，都是立刻返回，获取成功的话ngx\_accept\_mutex\_held被置为1。拿到锁，意味着监听句柄被放到本进程的epoll中了，如果没有拿到锁，则监听句柄会被从epoll中取出。
13. **if** (ngx\_trylock\_accept\_mutex(cycle) == NGX\_ERROR) \{ 
14. **return**; 
15.  \} 
16. 
17. //拿到锁的话，置flag为NGX\_POST\_EVENTS，这意味着ngx\_process\_events函数中，任何事件都将延后处理，会把accept事件都放到ngx\_posted\_accept\_events链表中，epollin|epollout事件都放到ngx\_posted\_events链表中
18. **if** (ngx\_accept\_mutex\_held) \{ 
19.  flags |= NGX\_POST\_EVENTS; 
20. 
21.  \} **else** \{ 
22. //拿不到锁，也就不会处理监听的句柄，这个timer实际是传给epoll\_wait的超时时间，修改为最大ngx\_accept\_mutex\_delay意味着epoll\_wait更短的超时返回，以免新连接长时间没有得到处理
23. **if** (timer == NGX\_TIMER\_INFINITE 
24.  || timer > ngx\_accept\_mutex\_delay) 
25.  \{ 
26.  timer = ngx\_accept\_mutex\_delay; 
27.  \} 
28.  \} 
29.  \} 
30.  \} 
31. 。。。 。。。 
32. //linux下，调用ngx\_epoll\_process\_events函数开始处理
33.  (**void**) ngx\_process\_events(cycle, timer, flags); 
34. 。。。 。。。 
35. //如果ngx\_posted\_accept\_events链表有数据，就开始accept建立新连接
36. **if** (ngx\_posted\_accept\_events) \{ 
37.  ngx\_event\_process\_posted(cycle, &ngx\_posted\_accept\_events); 
38.  \} 
39. 
40. //释放锁后再处理下面的EPOLLIN EPOLLOUT请求
41. **if** (ngx\_accept\_mutex\_held) \{ 
42.  ngx\_shmtx\_unlock(&ngx\_accept\_mutex); 
43.  \} 
44. 
45. **if** (delta) \{ 
46.  ngx\_event\_expire\_timers(); 
47.  \} 
48. 
49.  ngx\_log\_debug1(NGX\_LOG\_DEBUG\_EVENT, cycle->log, 0, 
50. "posted events %p", ngx\_posted\_events); 
51. //然后再处理正常的数据读写请求。因为这些请求耗时久，所以在ngx\_process\_events里NGX\_POST\_EVENTS标志将事件都放入ngx\_posted\_events链表中，延迟到锁释放了再处理。
52. **if** (ngx\_posted\_events) \{ 
53. **if** (ngx\_threaded) \{ 
54.  ngx\_wakeup\_worker\_thread(cycle); 
55. 
56.  \} **else** \{ 
57.  ngx\_event\_process\_posted(cycle, &ngx\_posted\_events); 
58.  \} 
59.  \} 
60. ｝

从上面的注释可以看到，无论有多少个nginx worker进程，同一时刻只能有一个worker进程在自己的epoll中加入监听的句柄。这个处理accept的nginx worker进程置flag为NGX\_POST\_EVENTS，这样它在接下来的ngx\_process\_events函数（在linux中就是ngx\_epoll\_process\_events函数）中不会立刻处理事件，延后，先处理完所有的accept事件后，释放锁，然后再处理正常的读写socket事件。我们来看下ngx\_epoll\_process\_events是怎么做的：

**\[cpp\]** [view plain][] [copy][view plain]

1.  **static** ngx\_int\_t 
2.  ngx\_epoll\_process\_events(ngx\_cycle\_t \*cycle, ngx\_msec\_t timer, ngx\_uint\_t flags) 
3.  \{ 
4.  。。。 。。。 
5.   events = epoll\_wait(ep, event\_list, (**int**) nevents, timer); 
6.  。。。 。。。 
7.   ngx\_mutex\_lock(ngx\_posted\_events\_mutex); 
8.  
9.  **for** (i = 0; i < events; i++) \{ 
10.  c = event\_list\[i\].data.ptr; 
11. 
12. 。。。 。。。 
13. 
14.  rev = c->read; 
15. 
16. **if** ((revents & EPOLLIN) && rev->active) \{ 
17. 。。。 。。。 
18. //有NGX\_POST\_EVENTS标志的话，就把accept事件放到ngx\_posted\_accept\_events队列中，把正常的事件放到ngx\_posted\_events队列中延迟处理
19. **if** (flags & NGX\_POST\_EVENTS) \{ 
20.  queue = (ngx\_event\_t \*\*) (rev->accept ? 
21.  &ngx\_posted\_accept\_events : &ngx\_posted\_events); 
22. 
23.  ngx\_locked\_post\_event(rev, queue); 
24. 
25.  \} **else** \{ 
26.  rev->handler(rev); 
27.  \} 
28.  \} 
29. 
30.  wev = c->write; 
31. 
32. **if** ((revents & EPOLLOUT) && wev->active) \{ 
33. 。。。 。。。 
34. //同理，有NGX\_POST\_EVENTS标志的话，写事件延迟处理，放到ngx\_posted\_events队列中
35. **if** (flags & NGX\_POST\_EVENTS) \{ 
36.  ngx\_locked\_post\_event(wev, &ngx\_posted\_events); 
37. 
38.  \} **else** \{ 
39.  wev->handler(wev); 
40.  \} 
41.  \} 
42.  \} 
43. 
44.  ngx\_mutex\_unlock(ngx\_posted\_events\_mutex); 
45. 
46. **return** NGX\_OK; 
47. \}

看看ngx\_use\_accept\_mutex在何种情况下会被打开：

**\[cpp\]** [view plain][] [copy][view plain]

1.  **if** (ccf->master && ccf->worker\_processes > 1 && ecf->accept\_mutex) \{ 
2.   ngx\_use\_accept\_mutex = 1; 
3.   ngx\_accept\_mutex\_held = 0; 
4.   ngx\_accept\_mutex\_delay = ecf->accept\_mutex\_delay; 
5.  
6.  \} **else** \{ 
7.   ngx\_use\_accept\_mutex = 0; 
8.  \}

当nginx worker数量大于1时，也就是多个进程可能accept同一个监听的句柄，这时如果配置文件中accept\_mutex开关打开了，就将ngx\_use\_accept\_mutex置为1。

再看看有些负载均衡作用的ngx\_accept\_disabled是怎么维护的，在ngx\_event\_accept函数中：

**\[cpp\]** [view plain][] [copy][view plain]

1.  ngx\_accept\_disabled = ngx\_cycle->connection\_n / 8 
2.   \- ngx\_cycle->free\_connection\_n;

表明，当已使用的连接数占到在nginx.conf里配置的worker\_connections总数的7/8以上时，ngx\_accept\_disabled为正，这时本worker将ngx\_accept\_disabled减1，而且本次不再处理新连接。

最后，我们看下ngx\_trylock\_accept\_mutex函数是怎么玩的：

**\[cpp\]** [view plain][] [copy][view plain]

1.  ngx\_int\_t 
2.  ngx\_trylock\_accept\_mutex(ngx\_cycle\_t \*cycle) 
3.  \{ 
4.  //ngx\_shmtx\_trylock是非阻塞取锁的，返回1表示成功，0表示没取到锁
5.  **if** (ngx\_shmtx\_trylock(&ngx\_accept\_mutex)) \{ 
6.  
7.  //ngx\_enable\_accept\_events会把监听的句柄都塞入到本worker进程的epoll中
8.  **if** (ngx\_enable\_accept\_events(cycle) == NGX\_ERROR) \{ 
9.   ngx\_shmtx\_unlock(&ngx\_accept\_mutex); 
10. **return** NGX\_ERROR; 
11.  \} 
12. //ngx\_accept\_mutex\_held置为1，表示拿到锁了，返回
13.  ngx\_accept\_events = 0; 
14.  ngx\_accept\_mutex\_held = 1; 
15. 
16. **return** NGX\_OK; 
17.  \} 
18. 
19. //处理没有拿到锁的逻辑，ngx\_disable\_accept\_events会把监听句柄从epoll中取出
20. **if** (ngx\_accept\_mutex\_held) \{ 
21. **if** (ngx\_disable\_accept\_events(cycle) == NGX\_ERROR) \{ 
22. **return** NGX\_ERROR; 
23.  \} 
24. 
25.  ngx\_accept\_mutex\_held = 0; 
26.  \} 
27. 
28. **return** NGX\_OK; 
29. \}

OK，关于锁的细节是如何实现的，这篇限于篇幅就不说了，下篇帖子再来讲。现在大家清楚nginx是怎么处理惊群了吧？简单了说，就是同一时刻只允许一个nginx worker在自己的epoll中处理监听句柄。它的负载均衡也很简单，当达到最大connection的7/8时，本worker不会去试图拿accept锁，也不会去处理新连接，这样其他nginx worker进程就更有机会去处理监听句柄，建立新连接了。而且，由于timeout的设定，使得没有拿到锁的worker进程，去拿锁的频繁更高。

[Linux]: http://lib.csdn.net/base/linux
[Link 1]: http://lib.csdn.net/base/softwaretest
[view plain]: http://blog.csdn.net/russell_tao/article/details/7204260#