[原创+转载] memcached源码学习-多线程模型
本来计划研究memcached的多线程模型，后来发现网上博文《Memcached源码分析(线程模型)》写的非常好，因此，也省去了我的大部分时间，这里并不打算自己再重新总结。不过首先奉上我自己画的一张图，就称为memcached多线程交互的活动图吧，通过此图就基本掌握了main thread与单个worker thread的交互过程，图中序号表示基本的处理流程（图中driver_machine拼写错误，应为drive_machine，特此更正）。
下图为状态机，红色部分由具体的conn的运行状态决定：
main thread在监听socket上注册EV_READ事件时，TCP设置conn状态为conn_listening，所以每次有新的连接请求时，因为conn_listening不存在向其它状态转换的路径，所以它只调用drive_machine中的conn_listening处理分支，其并不会执行其它部分；UDP直接创建一个状态为conn_read的conn，将其放入workerthread的new_conn_queue队列中。
conn_listening处理中接收的新连接状态设置为conn_new_cmd。所以worker thread接收数据的的处理过程从conn_new_cmd部分代码开始，正常的流程为：conn_new_cmd->conn_parse_cmd，之后process_command处理各种不同的cmd（参照memcached协议）。
不知道是有些状态用不到，还是状态机没有画完全，存在不可到达状态。
下面是对《Memcached源码分析(线程模型)》一文的引用：
[由于memcached的版本不同，下面会存在不同，不过基本流程相同]
先看下memcahced启动时线程处理的流程
memcached的多线程主要是通过实例化多个libevent实现的,分别是一个主线程和n个workers线程。
无论是主线程还是workers线程全部通过libevent异步事件模型来管理网络事件，实际上每个线程都是一个单独的libevent实例。
主线程负责监听客户端建立连接的请求，以及accept建立连接；
workers线程负责处理已经建立好的连接的读写等事件。
先看一下大致的图示：
首先看下主要的数据结构(thread.c)：
[*]/* An item in the connection queue. */
[*]typedef struct conn_queue_item CQ_ITEM;
[*]struct conn_queue_item {
[*] int sfd;
[*] int init_state;
[*] int event_flags;
[*] int read_buffer_size;
[*] int is_udp;
[*] CQ_ITEM *next;
[*]};
CQ_ITEM 实际上是主线程accept后返回的已建立连接的fd的封装
[*]/* A connection queue. */
[*]typedef struct conn_queue CQ;
[*]struct conn_queue {
[*] CQ_ITEM *head;
[*] CQ_ITEM *tail;
[*] pthread_mutex_t lock;
[*] pthread_cond_tcond;
[*]};
CQ是一个管理CQ_ITEM的单向链表
[*]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 */
[*] CQnew_conn_queue; /* queue of new connections to handle */
[*]} LIBEVENT_THREAD;
这是memcached里的线程结构的封装，可以看到每个线程都包含一个CQ队列，一条通知管道pipe
和一个libevent的实例event_base。
另外一个重要的最重要的结构是对每个网络连接的封装conn
[*]typedef struct{
[*]int sfd;
[*]int state;
[*]struct event event;
[*]short which;
[*]char *rbuf;
[*]... //这里省去了很多状态标志和读写buf信息等
[*]}conn;
memcached主要通过设置/转换连接的不同状态，来处理事件（核心函数是drive_machine）
下面看下线程的初始化流程：
在memcached.c的main函数中，首先对主线程的libevent做了初始化
[*]/* initialize main thread libevent instance */
[*] main_base = event_init();
然后初始化所有的workers线程，并启动，启动过程细节在后面会有描述
[*]/* start up worker threads if MT mode */
[*]thread_init(settings.num_threads, main_base);
接着主线程调用（这里只分析tcp的情况，目前memcached支持udp方式）
[*]server_socket(settings.port, 0)
这个方法主要是封装了创建监听socket，绑定地址，设置非阻塞模式并注册监听socket的
libevent 读事件等一系列操作
然后主线程调用
[*]/* enter the event loop */
[*]event_base_loop(main_base, 0);
这时主线程启动开始通过libevent来接受外部连接请求，整个启动过程完毕
下面看看thread_init是怎样启动所有workers线程的，看一下thread_init里的核心代码
[*]void thread_init(int nthreads, struct event_base *main_base) {
[*] //。。。省略
[*] threads = malloc(sizeof(LIBEVENT_THREAD) * nthreads);
[*] if (! threads) {
[*] perror("Can't allocate thread descriptors");
[*] exit(1);
[*] }
[*]
[*] // 原作者的memcached版本为1.2.6，不知道什么原因，这里存在错误，请以最新代码为准
[*] threads.base = main_base;
[*] threads.thread_id = pthread_self();
[*] // i从0开始，会冲掉上面的赋值，下面红色部分解释。
[*] for (i = 0; i < nthreads; i++) {
[*] int fds;
[*] if (pipe(fds)) {
[*] perror("Can't create notify pipe");
[*] exit(1);
[*] }
[*]
[*] threads.notify_receive_fd = fds;
[*] threads.notify_send_fd = fds;
[*]
[*] setup_thread(&threads);
[*] }
[*]
[*] /* Create threads after we've done all the libevent setup. */
[*] for (i = 1; i < nthreads; i++) {
[*] create_worker(worker_libevent, &threads);
[*] }
[*]}
threads的声明是这样的
static LIBEVENT_THREAD *threads;
thread_init首先malloc线程的空间，然后第一个threads作为主线程，其余都是workers线程
然后为每个线程创建一个pipe，这个pipe被用来作为主线程通知workers线程有新的连接到达
看下setup_thread
[*]static void setup_thread(LIBEVENT_THREAD *me) {
[*] if (! me->base) {
[*] me->base = event_init();
[*] if (! me->base) {
[*] fprintf(stderr, "Can't allocate event base\n");
[*] exit(1);
[*] }
[*] }
[*]
[*] /* Listen for notifications from other threads */
[*] event_set(&me->notify_event, me->notify_receive_fd,
[*] EV_READ | EV_PERSIST, thread_libevent_process, me);
[*] event_base_set(me->base, &me->notify_event);
[*]
[*] if (event_add(&me->notify_event, 0) == -1) {
[*] fprintf(stderr, "Can't monitor libevent notify pipe\n");
[*] exit(1);
[*] }
[*]
[*] cq_init(&me->new_conn_queue);
[*]}
setup_thread主要是创建所有workers线程的libevent实例（主线程的libevent实例在main函数中已经建立）
由于之前 threads.base = main_base;所以第一个线程（主线程）在这里不会执行event_init()
注：我看的memcached-1.4.7源码中，main thread线程不是放在threads位置的，而是在全局变量dispatcher_thread中保存，threads为全部的worker线程，其实对程序的理解影响并不大。
然后就是注册所有workers线程的管道读端的libevent的读事件，等待主线程的通知；
最后在该方法里将所有的workers的CQ初始化了。
create_worker实际上就是真正启动了线程，pthread_create调用worker_libevent方法，该方法执行
event_base_loop启动该线程的libevent。
这里我们需要记住每个workers线程目前只在自己线程的管道的读端有数据时可读时触发，并调用
thread_libevent_process方法
看一下这个函数
[*]static void thread_libevent_process(int fd, short which, void *arg){
[*] LIBEVENT_THREAD *me = arg;
[*] CQ_ITEM *item;
[*] char buf;
[*]
[*] if (read(fd, buf, 1) != 1)
[*] if (settings.verbose > 0)
[*] fprintf(stderr, "Can't read from libevent pipe\n");
[*]
[*] item = cq_peek(&me->new_conn_queue);
[*]
[*] if (NULL != item) {
[*] conn *c = conn_new(item->sfd, item->init_state, item->event_flags,
[*] item->read_buffer_size, item->is_udp, me->base);
[*] 。。。//省略
[*] }
[*]}
函数参数的fd是这个线程的管道读端的描述符
首先将管道的1个字节通知信号读出（这是必须的，在水平触发模式下如果不处理该事件，则会被循环通知，直到事件被处理）
cq_peek是从该线程的CQ队列中取队列头的一个CQ_ITEM,这个CQ_ITEM是被主线程丢到这个队列里的，item->sfd是已经建立的连接的描述符，通过conn_new函数为该描述符注册libevent的读事件，me->base是代表自己的一个线程结构体，就是说对该描述符的事件处理交给当前这个workers线程处理,conn_new方法的最重要的内容是：
[*]conn *conn_new(const int sfd, const int init_state, const int event_flags,
[*] const int read_buffer_size, const bool is_udp, struct event_base *base) {
[*] 。。。
[*] event_set(&c->event, sfd, event_flags, event_handler, (void *)c);
[*] event_base_set(base, &c->event);
[*] c->ev_flags = event_flags;
[*] if (event_add(&c->event, 0) == -1) {
[*] if (conn_add_to_freelist(c)) {
[*] conn_free(c);
[*] }
[*] perror("event_add");
[*] return NULL;
[*] }
[*] 。。。
[*]}
可以看到新的连接被注册了一个事件（实际是EV_READ|EV_PERSIST）,由当前线程处理（因为这里的event_base是该workers线程自己的）。
当该连接有可读数据时会回调event_handler函数，实际上event_handler里主要是调用memcached的核心方法drive_machine。
最后看看主线程是如何通知workers线程处理新连接的，主线程的libevent注册的是监听socket描述字的可读事件，就是说当有建立连接请求时，主线程会处理，回调的函数是也是event_handler（因为实际上主线程也是通过conn_new初始化的监听socket 的libevent可读事件）。
最后看看memcached网络事件处理的最核心部分- drive_machine
需要铭记于心的是drive_machine是多线程环境执行的，主线程和workers都会执行drive_machine
[*]static void drive_machine(conn *c) {
[*] bool stop = false;
[*] int sfd, flags = 1;
[*] socklen_t addrlen;
[*] struct sockaddr_storage addr;
[*] int res;
[*]
[*] assert(c != NULL);
[*]
[*] while (!stop) {
[*]
[*] switch(c->state) {
[*] case conn_listening:
[*] addrlen = sizeof(addr);
[*] if ((sfd = accept(c->sfd, (struct sockaddr *)&addr, &addrlen)) == -1) {
[*] //省去n多错误情况处理
[*] break;
[*] }
[*] if ((flags = fcntl(sfd, F_GETFL, 0)) < 0 ||
[*] fcntl(sfd, F_SETFL, flags | O_NONBLOCK) < 0) {
[*] perror("setting O_NONBLOCK");
[*] close(sfd);
[*] break;
[*] }
[*] dispatch_conn_new(sfd, conn_read, EV_READ | EV_PERSIST,
[*] DATA_BUFFER_SIZE, false);
[*] break;
[*]
[*] case conn_read:
[*] if (try_read_command(c) != 0) {
[*] continue;
[*] }
[*] ....//省略
[*] }
[*] }
首先大家不到被while循环误导（大部分做java的同学都会马上联想到是个周而复始的loop）其实while通常满足一个case后就会break了，这里用while是考虑到垂直触发方式下，必须读到EWOULDBLOCK错误才可以。
言归正传，drive_machine主要是通过当前连接的state来判断该进行何种处理，因为通过libevent注册了读写时间后回调的都是这个核心函数，所以实际上我们在注册libevent相应事件时，会同时把事件状态写到该conn结构体里，libevent进行回调时会把该conn结构作为参数传递过来，就是该方法的形参。
memcached里连接的状态通过一个enum声明
[*]enum conn_states {
[*] conn_listening,/** the socket which listens for connections */
[*] conn_read, /** reading in a command line */
[*] conn_write, /** writing out a simple response */
[*] conn_nread, /** reading in a fixed number of bytes */
[*] conn_swallow, /** swallowing unnecessary bytes w/o storing */
[*] conn_closing, /** closing this connection */
[*] conn_mwrite, /** writing out many items sequentially */
[*]};
实际对于case conn_listening:这种情况是主线程自己处理的，workers线程永远不会执行此分支
我们看到主线程进行了accept后调用了
dispatch_conn_new(sfd, conn_read, EV_READ | EV_PERSIST,DATA_BUFFER_SIZE, false);
这个函数就是通知workers线程的地方，看看
[*]void dispatch_conn_new(int sfd, int init_state, int event_flags,
[*] int read_buffer_size, int is_udp) {
[*] CQ_ITEM *item = cqi_new();
[*] int thread = (last_thread + 1) % settings.num_threads;
[*]
[*] last_thread = thread;
[*]
[*] item->sfd = sfd;
[*] item->init_state = init_state;
[*] item->event_flags = event_flags;
[*] item->read_buffer_size = read_buffer_size;
[*] item->is_udp = is_udp;
[*]
[*] cq_push(&threads.new_conn_queue, item);
[*]
[*] MEMCACHED_CONN_DISPATCH(sfd, threads.thread_id);
[*] if (write(threads.notify_send_fd, "", 1) != 1) {
[*] perror("Writing to thread notify pipe");
[*] }
[*]}
可以清楚的看到，主线程首先创建了一个新的CQ_ITEM，然后通过round robin策略选择了一个thread
并通过cq_push将这个CQ_ITEM放入了该线程的CQ队列里，那么对应的workers线程是怎么知道的呢
就是通过这个
write(threads.notify_send_fd, "", 1）
向该线程管道写了1字节数据，则该线程的libevent立即回调了thread_libevent_process方法（上面已经描述过），然后那个线程取出item,注册读时间，当该条连接上有数据时，最终也会回调drive_machine方法，也就是drive_machine方法的 case conn_read:等全部是workers处理的，主线程只处理conn_listening建立连接。
页:
[1]