Nginx源码剖析--连接池

前言

NGINX是一个http服务器。http基于tcp协议，tcp是基于连接的协议。也就是每个http请求都要在某个TCP连接上。在NGINX中，用一个结构体表示连接：

struct ngx_connection_s

每个连接都用一个ngx_connection_s结构体表示。每次监听socket accept到一个新的连接都会”新建”一个新的ngx_connection_s对应到这个连接，同时设置这个连接上的读写事件(ngx_event_t)：

struct ngx_connection_s {
void               *data;
ngx_event_t        *read;
ngx_event_t        *write;
....

ngx_connection_s 里面除了读写事件之外，还包括很多其他的属性，比如连接上对应的缓冲区等等(Buffer)。

显然如果每次新来连接都新建一个ngx_connection_s结构体的话，那效率显然太低了。因此Nginx设计了一个连接池。本文将介绍nginx中的连接池的设计。nginx的连接池大小在程序初始化时就固定了，后面不再扩大，因此nginx如何设计使得可以应付请求连接大于连接池规模是我们介绍的一个重点。同时本章也会介绍一下ngx_event_t。

连接池结构以及初始化

连接池结构在ngx_cycle_t的connections中：

cycle->connections

它是一个数组，这个数组的初始化在ngx_event_core_module模块的ngx_event_process_init函数中完成：

cycle->connections =
ngx_alloc(sizeof(ngx_connection_t) * cycle->connection_n, cycle->log);

其中cycle->connection_n表示连接的数目。这个数目是在event块的”worker_connections”或者”worker_connections”指令来设置的。指令函数是：ngx_event_connections。它是属于ngx_event_core_module模块的。如果没有显式设置的话，连接数目的默认值将是

#define DEFAULT_CONNECTIONS  512

连接池创建好之后，nginx开始初始化连接池，主要是设置连接池中每个连接对应的读写事件。这个过程也是在ngx_event_process_init函数中完成。为了为连接池中每个连接都对应一个读写事件，nginx分别维护了读写事件池：

cycle->read_events = ngx_alloc(sizeof(ngx_event_t) * cycle->connection_n,
cycle->log);
cycle->write_events = ngx_alloc(sizeof(ngx_event_t) * cycle->connection_n,
cycle->log);

可以看到读写事件池也是数组结构，并且他们的规模和连接池一样，这样就保证每个连接分别对应读，写连接池中一个事件：

i = cycle->connection_n;
next = NULL;

do {
i--;

c[i].data = next;
c[i].read = &cycle->read_events[i];
c[i].write = &cycle->write_events[i];
c[i].fd = (ngx_socket_t) -1;

next = &c[i];

#if (NGX_THREADS)
c[i].lock = 0;
#endif
} while (i);

这里可以看到，ngx_connection_t结构体中的data成员将连接池中所有的连接链接成一个链表。大循环使得连接池中所有的连接练成链表，顺序是最开始的在链表尾，最后加进去的在链表头。因此链表中的顺序和原始连接池的顺序是相反的。

到这里连接池基本就初始化完毕了。

不过既然是一个资源池，就要记录哪些资源可用，哪些资源不可用，也就是需要维护一个free链表：

cycle->free_connections = next;
cycle->free_connection_n = cycle->connection_n;

ngx_get_connection函数

这个函数就是从连接池中获取一个连接。更具体一点，就是从free_connections中获取一个连接：

//ngx_get_connection函数
c = ngx_cycle->free_connections;

if (c == NULL) {
ngx_drain_connections();
c = ngx_cycle->free_connections;
}

if (c == NULL) {
ngx_log_error(NGX_LOG_ALERT, log, 0,
"%ui worker_connections are not enough",
ngx_cycle->connection_n);

/* ngx_mutex_unlock */

return NULL;
}

ngx_cycle->free_connections = c->data;
ngx_cycle->free_connection_n--;

这里需要解决的一大难题就是free_connections中如果没有空间可用的连接怎么办？

nginx的做法是调用ngx_drain_connections函数。下面我们会看到这个函数会从一个队列中释放若干连接，而释放的连接会加入到free_connections 中。

ngx_drain_connections函数

这个函数做的工作很简单，就是将ngx_cycle->reusable_connections_queue队列中的connection的close置为1，然后调用该连接对应的读事件。每次调用这个函数最多会释放32条连接。在队列ngx_cycle->reusable_connections_queue中的连接都是正在使用的连接，如果调用ngx_drain_connections说明连接不够用了，因此需要把正在用的连接回收。当然也不是所有正在用的连接都可以被回收的，比如正在处理请求(请求还没接收完毕)的连接是不会被回收的。这个具体后面介绍nginx处理请求的时候再讲。

ngx_drain_connections将在reusable_connections_queue中的部分连接的close置为1之后，调用该连接对应的读事件处理器时，就会将连接close掉(以某个读事件处理器为例)：

//以ngx_http_wait_request_handler为例
if (c->close) {
ngx_http_close_connection(c);
return;
}

这个里面会调用ngx_close_connection，将该连接(事件处理器和连接是一一对应的)从reusable_connections_queue中删掉，然后将其加入到free_connections中：

....
ngx_reusable_connection(c, 0);//为0表示将其从回收队列中删除，反则将其计入回收队列
...
ngx_free_connection(c);
......

这样，free_connections中又有新的连接可以用了。

一些问题

这里有一个问题是：

由于回收的连接都是正在被使用的连接，那如果连接被回收后，原来的连接上的事件被触发了，怎么办呢？

第一次看到这个这个问题时，第一反应是，这种情况不可能发生吧。因为回收连接前都会调用ngx_close_connection函数，而这个函数会将该连接关联的事件从epoll中解除掉。这样子的话，该连接被回收后，连接上对应的事件不可能再被触发，因此上述问题不应该存在。

上面的考虑是不全面的。

因为上面的考虑基于一个假设，就是epoll中触发的各个事件之间不会相互影响，也就是不会出现某个被触发的事件把另一个事件的fd给close掉类似这种情况。但是事实这种情况是会出现的。

比如在某次epoll_wait返回两个事件event1,event2。在事件处理循环中event1的事件处理器先执行，不过不巧的是event1的事件处理器刚好是accept新连接，但是连接池中连接不够用，这时就会回收连接，而正好又回收了event2上对应的连接，这样上述问题就会出现了。也就是event2上的事件就变stale了。

因此我们需要一种方式来标记事件是否有效。当event2执行事件处理器前，先判断事件的有效性。nginx用ngx_event_t中的instance变量来解决这个问题。

也就是每次取一个新连接时都将ngx_event_t->instance取反：

\\ngx_get_connection
.....
instance = rev->instance;

ngx_memzero(rev, sizeof(ngx_event_t));
ngx_memzero(wev, sizeof(ngx_event_t));

rev->instance = !instance;
wev->instance = !instance;
....

在将事件添加到epoll中时，就会将这个instance标志存储到event.data.ptr中:

\\以ngx_epoll_add_event为例
ee.data.ptr = (void *) ((uintptr_t) c | ev->instance);//无论是32位还是64位机器，其地址的最后一位肯定是0（利用了指针的最后一位一定是0这一特性）

这样，如果事件过期的话，那事件结构体中对应的instance和ee.data.ptr中存储的instance会不一致：

\\以ngx_epoll_process_events为例
.....
instance = (uintptr_t) c & 1;
c = (ngx_connection_t *) ((uintptr_t) c & (uintptr_t) ~1);

rev = c->read;

if (c->fd == -1 || rev->instance != instance) {
.....

这样就达到了判断事件是否过期(连接是否被回收)的目的。

通过两个条件判断事件是否过期，一个是c->fd，一个是instance。c->fd主要是用来判断该事件对应的fd是否已经被关闭了。rev->instance是用来判断这个被激活事件对应的connection是不是已经被回收给其他fd使用了。因为每次connection，以及对应的rev,wev被新的fd重新使用时，都会对rev->instance和wev->instance取反。

不过这里还有一个问题：

假设一个epoll_wait返回时，有三个事件等待处理：A,B,C。其中A是一个accept事件，它回收了C的对应的connection。这样，C对应的event_list[i].data.ptr中的instance标记为将和它的rev->instance和wev->instance不一样(因为A回收时对它取反了)。但是接下来B也是一个accept事件，它又把A中新建立的连接回收了，这样它又对这个connection中的rev->instance,wev->instance取反。好了，现在问题出现了，由于两次取反，rev->instance和wev->instance又变回了原来的值，使得事件循环处理到C事件时，C在检查它的event_list[i].data.ptr中的instance和rev->instance，wev->instance时，发现它们又是相等的了。但是事实上，现在这个connection设施已经和C事件没什么关系了。这将会发生严重错误。

这个问题在使用post队列时是不会出现的。因为当某个connection被回收时，它上面的事件会被从post队列中删掉。

然而，对于不用post队列的情况，我也搞不懂了，难道是nginx的一个bug？？

总结

这篇博文写了两周，主要是后面的那个instance两次取反回到原来的值怎么解决的问题没搞懂。现在依旧不清楚，希望懂的大佬指导一二。这几天为这事以及毕业论文着实焦虑的慌。

总的来说，nginx实现了一个连接池，连接池是一个数组，同时nginx还分别维护了读事件数组和写事件数组，规模和连接池一样。一个读事件对应一个写事件，对应一个连接。而且nginx实现了流动性很强的回收池，在应对高并发时很有用处。

nginx是一个多进程的服务器，每个进程都维护相同规模的连接池，因此总的并发量(同一个时刻可以处理的总连接数)应该是: process_num * woker_connection。对于一个时间段，由于可以回收连接，那可处理的连接数就很多了。

就写到这里吧。