memcache代码走读：接入模型

希望写完这一系列文章，小程们可以对照memcache的源码全部看明白。第一篇文章先将memcache的网络接入，写的很是精彩。

 

memcache的接入层是依赖与libevent框架的，由其帮助管理I/O多路复用。不过，这里不对libevent做过多的介绍，以后我会陆续写关于libevent的文章，本文重点关注memcache接入层的编程艺术。姑且当libevent是个黑盒子吧。

 

memcache的接入是由一个主线程和一组worker线程（至少一个线程）协同完成，是一个Master-worker模式。Master负责接入请求，然后指定一个Worker去处理。Worker线程由一个简单的hash算法管理，基本可以理解为循环挨着取线程处理请求，简单的图示：

 

Master通知Worker的方式有点好玩，是通过管道来通知的。这样对于编码来说方便了很多，因为很多细节都交给内核处理，逻辑不用关心太多。

 

好了，现在梳理一下memcache的各个接入对象。

1，线程对象，pthread类型的线程被memcache封装成一个结构，与libevent有机的结合起来。

typedef struct {
    pthread_t thread_id;        /* unique ID of this thread */
    struct event_base *base;    /* libevent handle this thread uses */
    struct event notify_event;  /* listen event for notify pipe */
    int notify_receive_fd;      /* receiving end of notify pipe */
    int notify_send_fd;         /* sending end of notify pipe */
    struct thread_stats stats;  /* Stats generated by this thread */
    struct conn_queue *; /* queue of new connections to handle */
    cache_t *suffix_cache;      /* suffix cache */
} LIBEVENT_THREAD;

 

详细讲一个其中的各个元素，对后续的逻辑的理解很有帮助。

thread_id,这个很容易了，线程的唯一ID

base，这是libevent的event_base对象，因为libevent并不是线程安全的，所以每个线程需要维护自己的event，并不能多个线程共用一个。

notify_event,上面我们提到，Mater通知Worker是通过管道通知的，Worker接受时间就是这个了

nofify_receive_fd,管道的接收端，创建后由上面的base来进行管理

notify_send_fd，管道的发送端，会由Master往里写数据

stats，统计用的，主要功能以后再说

new_conn_queue，Master收到请求后，会把请求打包后挂到一个想通知的Worker负责的列表里面，这就是那个列表指针

 

Master和Worker的初始化在thread_init里面完成。首先是Master，着重说明的是它的event_base就是全局变量main_base。

Worker会执行以下几步：

1）创建一个pipe，两端赋给自己的那俩变量。

2）初始化自己的event_base。

3）将notify_event，receive_fd,和回调函数thread_libevent_process关联起来，当Master通知过来时，这个Worker能够收到数据

4）初始化列表指针

5）初始化cash指针

 

2，连接对象

memcache将fd封装成一个连接对象，conn

这个对象里面的数据比较多，挑几个重点的说一下。

int    sfd;，连接的fd
conn_states  state; 描述conn状态的，所有状态的定义都在conn_states 里面
struct event event;
short  ev_flags;
short  which;   /** which events were just triggered */

LIBEVENT_THREAD *thread; 处理它的那个Worker线程指针

 

3，辅助连接对象

上面提到过，Master接收到请求后，会把这个请求打包挂到某一个Worker下面的new_conn_queue下面，这个下面挂的对象是conn_queue_item。

里面的变量不具体介绍了，只保留了conn对象的一部分与这个请求相关的一些数据。

 

 

现在，结合代码，说一下整个的接入流程（略去了很多写server的通用代码，比如接受参数，守护进程运行，更改limit参数等）。

1）首先，Master初始化自己的event_base

L:4588:

 /* initialize main thread libevent instance */
    main_base = event_init();

 

2,连接对象（conn）初始化 ，预先分配200个连接对象，即同时可以接受并处理200个客户端的请求

L：4594：

conn_init();

 

3，Master和Worker线程的初始化

L：4606

 /* start up worker threads if MT mode */
thread_init(settings.num_threads, main_base);

这个函数可以好好看看，里面的具体功能在上面已经讲过了。

 

4，如果是TCP模式就需要穿件套接字，并监听了。

L4665：

if (settings.udpport && server_socket(settings.udpport, udp_transport, portnumber_file))

这个函数是主要的接入函数，我会详细介绍它。

创建完套接字后会进入conn_new ，这个函数是接入层相当重要的一个函数，任何一个新的连接都会由这个函数来处理。它会把刚刚创建的套接字由传进来的event_base来管理。以后Worker收到

套接字会与event_handler绑定，当有时间发生时（这里是可读事件），会进入drive_machine函数，也就是memcache的状态机，是接入层与逻辑层的纽带，以后我会专门有文章来讲它，这里只介绍接受请求的逻辑。

 

Master线程监听了套接字后，当有请求过来时，就能捕获到了，经event_handler->drive_machine->dispatch_conn_new的路径。在dispatch_conn_new这个函数里面会看到主线程会创建一个辅助连接对象conn_queue_item，并把它挂到某个Worker下面。然后往管道写入一个字符，通知管道的另一端Worker，有请求来了。

 

 

Worker的event_base会收到请求，进入回调函数thread_libevent_process，把链表中的对象取出来，组成一个新的连接对象conn，这是通过conn_new来处理的，上面Master处理监听套接字时用的就是它，既然这样，我就好好的介绍一下这个函数。

 

首先，上面我们提到过，连接对象conn初始化时预先分配了200个对象空间，不过有请求来了之后竟然不从这里取用，这是最让我糊涂的地方，那初始化用来干什么呢？所以第一个请求需要重新申请空间。应用到代码中就是先执行

conn *c = conn_from_freelist();

会返回NULL，然后申请空间：

c = (conn *)calloc(1, sizeof(conn)))。

另外，conn对象有一个event变量，上面我们提到过。用event_set初始化，与从链表中取出的fd，和回调函数event_handler绑定。

L：422， event_set(&c->event, sfd, event_flags, event_handler, (void *)c);

L：423， event_base_set(base, &c->event);与该线程的event对象绑定，此后，这个fd就由这个线程的libevent来管理了。

当有请求来时，进入event_handler,进而进入状态机。