(nginx 源码系列二)-- 由读 nginx 源码想到的多进程下 accept 的处理方式

发表于 2015-04-26 更新于 2025-04-04 分类于 Nginx ， TCP 阅读次数： 119 本文字数： 5.1k 阅读时长 ≈ 5 分钟

nginx 源码本来应该放在 nginx 源码学习这一块。但是考虑到多进程下 accept 的处理可以单独拿出来讨论。所以还是单独一篇博客会比较好。

## nginx 的结构

简单提一下 nginx 的启动流程

核心文件当然是 core/nginx.c，main 函数就在这里。

而在 main 函数中，最重要的我认为是 nginx_init_cycle 和 ngx_master_process_cycle 这两个函数。前者负责解析配置文件，按配置文件进行配置初始化。后者将进入总事件循环中。

解析配置大致是按照 nginx_init_cycle->ngx_conf_parse->ngx_conf_handler 这样的顺序进行的，这里很重要是因为模块的配置命令函数都由这里来运行，并且设定了一系列回调来执行响应事件后的函数。nginx 的模块化就是依赖这个。

而进入总事件循环大致是按照 ngx_master_process_cycle->ngx_start_worker_processes->(fork)->ngx_worker_process_cycle->ngx_process_events_and_time->ngx_process_events (epoll 时实际上就是 ngx_epoll_process_events)->epoll_wait 的顺序进行的。

从调用顺序就能看得出来 nginx 是 master-worker 这样的设计结构。

master 只是负责启动，监控 worker。由 worker 来进行事件响应式的事件循环。

ngx_process_events_and_timers 函数基本流程是这样的：先判断 accept 锁是否闲置，闲置就占有该锁，然后运行 ngx_process_events 时，把 epoll_wait 收集到的活跃描述字组成事件分别放入 ngx_posted_accept_events (假如占有了 accept 锁的话) 和 ngx_posted_events 队列中。而后运行 ngx_event_process_posted 来调用这两个队列的回调。运行完 ngx_posted_accept_events 队列后就会释放 accept 锁，防止 accept 锁长时间被占用。这是为了提高高并发能力的。

由于将触发事件放入队列延后处理，这里就不得不提到 nginx 关于 stale event 的处理了。

### stale event

stale event 在 nginx 中存在有两种，一种是由于某连接同时存在 read 事件和 write 事件。因此会按顺序先运行 read 事件回调后执行 write 回调，如果 read 回调因为出错而把描述符关闭，那么此时执行 write 事件回调就会出错。因此需要对 stale event 做处理。这种处理比较常见，在大多数的 epoll 构成的事件库中都能看到。

另外一种是主要存在于 event cache 中前一个对象可能使得后一个对象失效的场景。例如队列中存在事件 A,B,C。如果 C 的 fd 是由于 A 的 upstream 产生的，那么当运行 A 回调出错时关闭 C 的连接后。如果 B upstream 执行了 ngx_get_connection 从连接池拿取连接时，很有可能就是使用了之前释放的那个连接。如果执行 C 的事件时，只是通过判断连接的 fd 是否被设置为 - 1。那么显然是无效的。这时就需要一种手段来解决 stale event 了。

epoll 给的建议是当释放一个描述符时，使用一个数据结构来存储这些描述符，这样就不会乱了。在这里也是适用的，相对的改成存储释放过的连接，或者把队列里的这个连接删除就行了。但是这样显然是低效的。涉及到操作最快也是 O (nlgn) 时间复杂度的。

redis 使用了一个 mask 标记位来处理。

static int aeApiPoll(aeEventLoop *eventLoop, struct timeval *tvp) 
{
        aeApiState *state = eventLoop->apidata;
        int retval, numevents = 0;

        retval = epoll_wait(state->epfd,state->events,AE_SETSIZE,
                tvp ? (tvp->tv_sec*1000 + tvp->tv_usec/1000) : -1);
        if (retval > 0) 
        {
            int j;

            numevents = retval;
            for (j = 0; j < numevents; j++) 
            {
                    int mask = 0;
                    struct epoll_event *e = state->events+j;

                    if (e->events & EPOLLIN) mask |= AE_READABLE;
                    if (e->events & EPOLLOUT) mask |= AE_WRITABLE;
                    eventLoop->fired[j].fd = e->data.fd;
                    eventLoop->fired[j].mask = mask;
            }
        }
        return numevents;
}
```  

可以看到eventLoop->fired数组记录了被epoll_wait触发的一轮中所有的mask值

```c
aeFileEvent *fe = &eventLoop->events[eventLoop->fired[j].fd];
int mask = eventLoop->fired[j].mask;
int rfired = 0;

/* note the fe->mask & mask & ... code: maybe an already processed
 * event removed an element that fired and we still didn't
 * processed, so we check if the event is still valid. */
if (fe->mask & mask & AE_READABLE) 
{
    rfired = 1;
    fe->rfileProc(eventLoop,fd,fe->clientData,mask);
}
if (fe->mask & mask & AE_WRITABLE) 
{
    if (!rfired || fe->wfileProc != fe->rfileProc)
    fe->wfileProc(eventLoop,fd,fe->clientData,mask);
}

此时将对 fe->mask & mask & AE_READABLE 以及 fe->mask & mask & AE_WRITABLE 判断，假如不同说明缓存的 event 已经过期了

另外当同时存在读事件和写事件时，通过 rfired 值，只会运行读事件的回调，防止读事件释放连接而使得写事件过期

可以看到，这种方式很清晰。

然而，nginx 使用了非常精巧的一种办法去处理。它利用了内存对齐的一字节冗余信息来判断，节省空间。

在 ngx_get_connection 函数中，连接的读事件和写事件都对一个 instance 变量取反。

而在 ngx_epoll_add_event 和 ngx_epoll_add_connection 函数中

c ee.data.ptr = (void *) ((uintptr_t) c | c->read->instance);

由于连接的地址变量第一位始终为 0，因此可以用来存储 instance 变量的值。

而后在 ngx_epoll_process_events 中，将会进行

c c->fd == -1 || rev->instance != instance

这样的判断，如果一个连接的 intance 被两次取反以后，当然就会和一开始存储在 epoll 结构中的指针中的 instance 不同了。也就能判断出 stale event 了。

然而这里依然有两个点没有说明，举实例来说明吧。

例如队列中存在事件 A,B,C,D,E。A 事件会关闭 E，B,C,D 都是接受连接事件，但是 B,C 再刚获取到连接时都失败了，此时 instance 被两次取反，然后 E 接受连接成功了，fd 不为 - 1，这时 stale event 就无法分辨了。但是这种情况不会出现，因为 accept 事件和其他事件是不同的队列，accept 事件在一轮 epoll 后会优先执行。也就是说实际的执行顺序是 B,C,D,A,E。因此这一点不需要担心。

另外一点是类似的，唯一的区别是此时 B,C,D 并非被动接受连接，而是主动发起连接，也就是使用 upstream 模块。我翻阅了代码的流程，这种情况理论上的确可能是会出现的。但是实际上不会出现。因为正常来说异步的 connect 调用会直接返回 NGX_AGAIN。因此一次 upstream 后进行 connect 操作后立刻就会返回，在同一轮的 epoll 处理中没有机会去释放连接。

当然，第二点这种情况只是我个人的猜测，查阅了资料，并没有人对这种理论可能出现 stale event 做讨论。如果有人有更好的解读，那么请为我解惑。

nginx 关于大并发的 tricks 还是很多的，不过我还没全看完，后面会继续分析。不过我觉得这个应该是比较有意思的了。

## 多进程下 accept 的处理方式

下面就聊聊我所知道的方式吧。这些方式都是主从结构的。

这些方法要解决的核心问题是如何在多进程 / 线程的情况下 hold 住更多的连接，这些都是半异步半同步模型变种的一种实际应用方式。

各个模型区别其实不是很大。当然我所读的开源项目较少，以后会继续完善这篇文章。

### nginx 方式

master 只是管理 worker

每个 worker 都可以 accept，都有独立的事件循环，通过负载均衡锁（实质是共享内存）来实现各个进程的均衡。

### ONESHOT 方式

master 进行 epoll_wait 且为唯一的事件循环，并且对 listen 的 fd 触发后进行 accept。在 add 事件时加入 EPOLLONESHOT 标记，使得该描述符虽然加入 epoll，但是在标记位没有被重置时只会触发一次。而后通过管道分发到 worker 线程

worker 线程实质是个线程池，在回调执行完毕后重置 EPOLLONESHOT 标记，以触发下一次事件。

EPOLLONESHOT 的使用，在我看来是由于事件循环和回调是异步处理而需要使用的，由于事件循环和回调异步，在不采取任何同步手段下，可能存在多个回调并行执行的可能，假如这些回调都是有状态的，例如下载时并未记录文件偏移量，而是靠回调的先后顺序来分别 append 在文件末尾。那么这样的过程就会出错。EPOLLONESHOT 是 epoll 的同步手段。

### 我的方式

这种方式在我的分布式文件系统项目 ydfs 可以看到 https://github.com/tedcy/ydfs

master 是一个 accept 的死循环，同时管理 worker 线程。当描述符被 accept 到时，使用负载均衡算法选择管道数组中的一个压入 accept 到的描述符，这个管道的另一端是某个 worker 线程。

worker 线程的 epoll_wait 感知到管道的活跃，将描述符读出，加入该线程的事件循环，然后就欢快的 run handle 了。

小结

这三种方式各有优劣。

nginx 方式的优点是多个进程进行 accept，系统的最大吞吐量是和核数成正比（性能好百万也不在话下），缺点是当所有进程恰好 handle 耗时较长时，accept 可能得不到处理。另外就是实现上需要使用一些手段，比如 accept 锁，事件缓存等等，而使用事件缓存就得考虑到 stale event 了。

ONESHOT 方式是我在书上看到的理论方式，似乎没看到开源实现。（这个优点缺点不好说，汗）

我的方式优点很明显，accept 是主线程，肯定是会不断的去接收连接的，accept 事件会被第一优先级去处理，另外编程也容易些，省去了例如 nginx 或者 ONESHOT 这样的同步方式。缺点也很明显，吞吐量大可能会达到单核极限，单核不足以去处理。但是应对文件系统来说，不太可能会出现这样的并发量，因为这只是存储层，应用层或者中间件层进行调用时肯定会使用连接池技术。根据我的测试，这种方式在应对 C10K 以及 C100K 问题时还是游刃有余的。

小结

未完待续