memcached源码剖析5：并发模型
网络连接建立与分发
前面分析了worker线程的初始化，以及主线程创建socket并监听的过程。本节会分析连接如何建立与分发。
初始状态
A，可以摸清楚master线程的大致逻辑：
1）初始化各个worker线程
2）执行socket，bind，listen...主线程进行监听
3）一旦有新的连接建立，则调用event_handler
B，woker线程被创建之后的逻辑：
1）监听管道recv端的fd，一旦有数据过来，则调用thread_libevent_process
注意，worker线程其实也是利用event_base_loop将自己进行阻塞。主线程阻塞在监听的fd上，而worker线程则阻塞在监听管道recv端的fd上。回忆一下前文，memcached_thread_init函数中建立了管道，用于master线程和worker线程间的通信。只有master线程接受了新的请求之后，才会利用管道告知worker线程，而worker线程只有等管道有数据传输来的时候，才会被唤醒。
用图展现初始状态下的master和worker线程：
图中假设主线程socket函数返回的fd是26。可以看到master线程以及4条worker线程，都因为没有任何事件而处于阻塞状态。
另外，前文提到一个很重要的结构体conn，conns数组由conn指针组成。memcahed的每个连接都对应有一个conn实例，可以根据fd在conns数组里找到。由于master线程的套接口是26，所以conns[26]的指向的conn就表示master线程正监听的socket以及一些附加信息。
marster线程接收与分发
我们来模拟一下有连接过来时，memcached内部的执行。前文提到，一旦有连接过来，则master线程会被触发执行event_handler函数。
void event_handler(const int fd, const short which, void *arg) {
conn *c;
c = (conn *)arg;
assert(c != NULL);
c->which = which;
/* sanity */
if (fd != c->sfd) {
if (settings.verbose > 0)
fprintf(stderr, "Catastrophic: event fd doesn't match conn fd!\n");
conn_close(c);
return;
}
// 主要逻辑全部封装在drive_machine中
drive_machine(c);
/* wait for next event */
return;
}
event_handler中传入的conn，就是conns[26]。
drive_machine
在event_handler里会继续将这个conn传递给drive_machine。
static void drive_machine(conn *c) {
bool stop = false;
int sfd;
socklen_t addrlen;
struct sockaddr_storage addr;
int nreqs = settings.reqs_per_event;
int res;
const char *str;
#ifdef HAVE_ACCEPT4
static int use_accept4 = 1;
#else
static int use_accept4 = 0;
#endif
assert(c != NULL);
// 一个大的while循环，维护了一个状态机，根据conn的当前状态做出处理，跳到下一状态
while (!stop) {
switch(c->state) {
// 初始状态为conn_listening
case conn_listening:
addrlen = sizeof(addr);
// accept连接，会产生一个新的fd，该连接之后的读写均通过新fd完成
#ifdef HAVE_ACCEPT4
if (use_accept4) {
sfd = accept4(c->sfd, (struct sockaddr *)&addr, &addrlen, SOCK_NONBLOCK);
} else {
sfd = accept(c->sfd, (struct sockaddr *)&addr, &addrlen);
}
#else
sfd = accept(c->sfd, (struct sockaddr *)&addr, &addrlen);
#endif
// accept失败
if (sfd == -1) {
// 如果是accept4未被实现，则换用accept继续尝试接受连接
if (use_accept4 && errno == ENOSYS) {
use_accept4 = 0;
continue;
}
perror(use_accept4 ? "accept4()" : "accept()");
// 如果连接队列已经没有未处理的连接，则终止循环
if (errno == EAGAIN || errno == EWOULDBLOCK) {
/* these are transient, so don't log anything */
stop = true;
}
// 连接打满，accept_new_conns(false)会终止event继续触发
else if (errno == EMFILE) {
if (settings.verbose > 0)
fprintf(stderr, "Too many open connections\n");
accept_new_conns(false);
stop = true;
} else {
perror("accept()");
stop = true;
}
break;
}
// 设置新的套接字为非阻塞
if (!use_accept4) {
if (fcntl(sfd, F_SETFL, fcntl(sfd, F_GETFL) | O_NONBLOCK) < 0) {
perror("setting O_NONBLOCK");
close(sfd);
break;
}
}
if (settings.maxconns_fast &&
stats_state.curr_conns + stats_state.reserved_fds >= settings.maxconns - 1) {
str = "ERROR Too many open connections\r\n";
res = write(sfd, str, strlen(str));
close(sfd);
STATS_LOCK();
stats.rejected_conns++;
STATS_UNLOCK();
} else {
// ！！！分发并通知worker线程有一个新的连接
dispatch_conn_new(sfd, conn_new_cmd, EV_READ | EV_PERSIST,
DATA_BUFFER_SIZE, c->transport);
}
stop = true;
break;
case conn_waiting:
...
case conn_read:
...
case conn_parse_cmd :
...
case conn_new_cmd:
...
case conn_nread:
...
case conn_swallow:
...
case conn_write:
...
case conn_mwrite:
...
case conn_closing:
...
case conn_closed:
...
case conn_watch:
...
case conn_max_state:
...
}
}
return;
}
前文曾提到drive_machine是一个大的状态机。上面的代码只保留了对conn_listening的处理，因为master线程接受新连接时，就是这个状态。
代码里调用accept4或者accept函数产生新的fd，为27。accept之后，主要就是调用dispatch_conn_new来对连接做分发，并且通知worker线程。
dispatch_conn_new
我们来看dispatch_conn_new的实现：
void dispatch_conn_new(int sfd, enum conn_states init_state, int event_flags,
int read_buffer_size, enum network_transport transport) {
// CQ_ITEM用于封装新连接的一些信息
CQ_ITEM *item = cqi_new();
char buf[1];
if (item == NULL) {
close(sfd);
/* given that malloc failed this may also fail, but let's try */
fprintf(stderr, "Failed to allocate memory for connection object\n");
return ;
}
// 挑选worker线程，采用轮循机制
int tid = (last_thread + 1) % settings.num_threads;
LIBEVENT_THREAD *thread = threads + tid;
last_thread = tid;
// 设置item
item->sfd = sfd;
item->init_state = init_state;
item->event_flags = event_flags;
item->read_buffer_size = read_buffer_size;
item->transport = transport;
// 将item放入线程的new_conn_queue队列
cq_push(thread->new_conn_queue, item);
MEMCACHED_CONN_DISPATCH(sfd, thread->thread_id);
// 通过管道，写入一字节的c，用来达到通知子线程的目的
buf[0] = 'c';
if (write(thread->notify_send_fd, buf, 1) != 1) {
perror("Writing to thread notify pipe");
}
}
可以很明显的看到，worker线程的分发是采用轮循机制的，每次选出来的都是threads数组中的下一个。
CQ_ITEM与conn_queue队列
CQ_ITEM结构体用于封装新accept的连接的一些相关信息，每个线程内部都维护着一个CQ_ITEM队列。当主线程通过管道写入字符c之后，子线程会被通知到，有一个新的连接来了。于是，子线程随后立即从CQ_ITEM队列中取出CQ_ITEM，并对这个新的连接设置监听事件等等。子线程具体的实现，后面会分析到，这里先看下CQ_ITEM：
typedef struct conn_queue_item CQ_ITEM;
struct conn_queue_item {
int sfd; // accept产生的新fd
enum conn_states init_state; // 子线程拿到新的连接之后，连接对应的状态
int event_flags; // 子线程对新连接设置的事件
int read_buffer_size; // 一般2M
enum network_transport transport; // tcp or udp
conn *c;
CQ_ITEM *next;
};
好，至此我们已经看完了主线程所做的工作。
只要不断的有新连接进来，主线程就会不断调用event_handler，并在drive_machine状态机中accept & dispatch连接。至于接下来，接收客户端发来的命令并做出响应等等，都是在worker线程里完成。
这张图画出了子线程中的CQ_ITEM队列，以及主线程通过管道告知子线程。
注意worker1线的连接，fd分别是27,31,35...因为中间其他fd对应的连接会分别被worker2，worker3，worker4处理。
另外借用一张其他博客的图，也挺清楚的：
worker线程设置监听
本小节开始看worker线程获取通知之后，所做的一些处理。前文说到，marster线程会向管道写入一个字符'c'，用来告知worker线程有新的连接了。于是worker线程监听管道的事件被触发，worker线程会进入thread_libevent_process函数：
static void thread_libevent_process(int fd, short which, void *arg) {
LIBEVENT_THREAD *me = arg;
CQ_ITEM *item;
char buf[1];
unsigned int timeout_fd;
// 从管道里读取一个字节
if (read(fd, buf, 1) != 1) {
if (settings.verbose > 0)
fprintf(stderr, "Can't read from libevent pipe\n");
return;
}
switch (buf[0]) {
// 字符c
case 'c':
// item是从new_conn_queue队列中取出的一个CQ_ITEM对象
item = cq_pop(me->new_conn_queue);
if (NULL != item) {
// 调用conn_new来创建conn，并且设置监听事件
conn *c = conn_new(item->sfd, item->init_state, item->event_flags,
item->read_buffer_size, item->transport,
me->base);
if (c == NULL) {
if (IS_UDP(item->transport)) {
fprintf(stderr, "Can't listen for events on UDP socket\n");
exit(1);
} else {
if (settings.verbose > 0) {
fprintf(stderr, "Can't listen for events on fd %d\n",
item->sfd);
}
close(item->sfd);
}
} else {
c->thread = me;
}
// 释放item
cqi_free(item);
}
break;
case 'r':
...
case 'p':
...
case 't':
...
}
}
注意conn_new函数，conn_new在前文出现过（server_socket函数中用conn_new创建了conns[26]）。本例中，conn_new执行完之后，会新创建一个conn对象，并且将conns[27]指向它，从此以后，线程worker1就利用该conn来与客户端交互。
值得一提的是，新的conn中，state被置为conn_new_cmd，表明该连接已经建立，等待接受client发送的命令。而主线程所使用的conns[26]，state永远为conn_listening，表明主线程一直在等待新的连接。
在conn_new中，设置事件的语句为：
event_set(&c->event, sfd, event_flags, event_handler, (void *)c);
event_base_set(base, &c->event);
可见，子线程的事件被触发之后，也是调用event_handler函数，和主线程的事件触发的函数一样。
回忆下event_handler中的状态机，worker线程的conn初始状态为conn_new_cmd，所以一旦worker线程接受到client的命令，便会进入drive_machine中的case conn_new_cmd分支。当然这涉及到后续具体的命令处理，已经不在本文的探讨范畴了。
最后来看一下worker线程thread_libevent_process处理完毕之后的状态：
本作品由driftcloudy创作，采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。欢迎自行转载，发布，演绎，但必须保留本文作者署名driftcloudy（包含链接http://www.cnblogs.com/driftcloudy），且不得用于商业目的。
