Memcached源码分析之memcached.c

时间：2016-09-07 17:26:55 阅读：299 评论：0 收藏：0 [点我收藏+]

标签：

memcached.c 由于代码太多，在此省略了部分代码，例如UPD连接，二进制协议，某些错误输出和调试输出等，建议从main函数开始看起。

#include "memcached.h"
//尝试从socket中读取数据的结果枚举
enum try_read_result {
READ_DATA_RECEIVED,
READ_NO_DATA_RECEIVED,
READ_ERROR, /** an error occured (on the socket) (or client closed connection) */
READ_MEMORY_ERROR /** failed to allocate more memory */
};
struct stats stats; //全局统计变量
struct settings settings; //全局配置变量
static conn *listen_conn = NULL; //全局的监听连接对象
static int max_fds; //fds上限
static struct event_base *main_base; //主线程的event_base 对象
//向客户端发送数据的结果枚举
enum transmit_result {
TRANSMIT_COMPLETE, /** All done writing. */
TRANSMIT_INCOMPLETE, /** More data remaining to write. */
TRANSMIT_SOFT_ERROR, /** Can‘t write any more right now. */
TRANSMIT_HARD_ERROR /** Can‘t write (c->state is set to conn_closing) */
};
extern pthread_mutex_t conn_lock; //连接锁
/**
创建连接函数，参数为：
sfd 要监听的socket fd
init_state 连接的初始化状态conn_states
event_flags 监听的事件
read_buffer_size 读缓存大小
transport 监听的socket 类型
base event_base
每监听一个fd（listen fd和client fd）都会创建这样一个conn来保存相关信息，表示一个“连接”，
无论连接是已经连接上了，还是仅仅处于listen状态。
*/
conn *conn_new(const int sfd, enum conn_states init_state,
const int event_flags,
const int read_buffer_size, enum network_transport transport,
struct event_base *base) {
conn *c;
assert(sfd >= 0 && sfd < max_fds);
c = conns[sfd];
if (NULL == c) {
if (!(c = (conn *)calloc(1, sizeof(conn)))) {
STATS_LOCK();
stats.malloc_fails++;
STATS_UNLOCK();
fprintf(stderr, "Failed to allocate connection object\n");
return NULL;
}
MEMCACHED_CONN_CREATE(c);
c->rbuf = c->wbuf = 0;
//c->xx省略部分初始化代码
c->hdrsize = 0;
c->rbuf = (char *)malloc((size_t)c->rsize);
c->wbuf = (char *)malloc((size_t)c->wsize);
c->ilist = (item **)malloc(sizeof(item *) * c->isize);
c->suffixlist = (char **)malloc(sizeof(char *) * c->suffixsize);
c->iov = (struct iovec *)malloc(sizeof(struct iovec) * c->iovsize);
c->msglist = (struct msghdr *)malloc(sizeof(struct msghdr) * c->msgsize);
if (c->rbuf == 0 || c->wbuf == 0 || c->ilist == 0 || c->iov == 0 ||
c->msglist == 0 || c->suffixlist == 0) {
conn_free(c);
STATS_LOCK();
stats.malloc_fails++;
STATS_UNLOCK();
fprintf(stderr, "Failed to allocate buffers for connection\n");
return NULL;
}
STATS_LOCK();
stats.conn_structs++;
STATS_UNLOCK();
c->sfd = sfd;
conns[sfd] = c;
}
c->transport = transport;
c->protocol = settings.binding_protocol;
if (!settings.socketpath) {
c->request_addr_size = sizeof(c->request_addr);
} else {
c->request_addr_size = 0;
}
if (transport == tcp_transport && init_state == conn_new_cmd) {
if (getpeername(sfd, (struct sockaddr *) &c->request_addr,
&c->request_addr_size)) {
perror("getpeername");
memset(&c->request_addr, 0, sizeof(c->request_addr));
}
}
if (settings.verbose > 1) {
//省略向终端输出调试的代码
}
c->state = init_state;
//c->xxx 省略部分初始化代码
c->noreply = false;
//创建事件，处理函数为event_handler，并把conn 连接对象传入event_handler中。
//（主线程调用conn_new时：）在主线程，创建完listenfd后，调用此函数监听网络连接事件，此时conn对象的conn_state为conn_listening
/**（建议看到worker线程调用conn_new时才看以下解析）
（worker线程调用conn_new时）在worker线程，收到主线程丢过来的client fd时，调用此函数监听来自client fd的网络事件。
也就是说，无论是主线程还是worker线程，都会调用此函数conn_new，创建conn连接对象，同时监听各自的fd。
而且都是调用event_handler作处理，只是不一样的fd, 不一样的conn对象（即下面的（void *） c）
进入 event_handler看看都做了啥？
*/
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) { //把事件加入监听
perror("event_add");
return NULL;
}
STATS_LOCK();
stats.curr_conns++;
stats.total_conns++;
STATS_UNLOCK();
MEMCACHED_CONN_ALLOCATE(c->sfd);
return c;
}
//向客户端输出字符串
static void out_string(conn *c, const char *str) {
size_t len;
assert(c != NULL);
if (c->noreply) {
if (settings.verbose > 1)
fprintf(stderr, ">%d NOREPLY %s\n", c->sfd, str);
c->noreply = false;
conn_set_state(c, conn_new_cmd);
return;
}
if (settings.verbose > 1)
fprintf(stderr, ">%d %s\n", c->sfd, str);
/* Nuke a partial output... */
c->msgcurr = 0;
c->msgused = 0;
c->iovused = 0;
add_msghdr(c); //添加一个msghdr
len = strlen(str);
if ((len + 2) > c->wsize) {
/* ought to be always enough. just fail for simplicity */
str = "SERVER_ERROR output line too long";
len = strlen(str);
}
memcpy(c->wbuf, str, len); //把要发送的字符串写入wbuf字段中
memcpy(c->wbuf + len, "\r\n", 2); //添加换行回车符
c->wbytes = len + 2;
c->wcurr = c->wbuf;
conn_set_state(c, conn_write); //把连接状态设置为conn_write，则状态机进入conn_write分支执行输出
c->write_and_go = conn_new_cmd; //当状态机完成输出后要切换到的状态为conn_new_cmd
return;
}
/**
无法分配内存时经常会调用此函数，例如内存空间已满，但又无法淘汰旧的item时，则向客户端响应一个错误
*/
static void out_of_memory(conn *c, char *ascii_error) {
const static char error_prefix[] = "SERVER_ERROR ";
const static int error_prefix_len = sizeof(error_prefix) - 1;
if (c->protocol == binary_prot) {
/* Strip off the generic error prefix; it‘s irrelevant in binary */
if (!strncmp(ascii_error, error_prefix, error_prefix_len)) {
ascii_error += error_prefix_len;
}
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, ascii_error, 0);
} else {
out_string(c, ascii_error);
}
}
/*
* 解析文本协议时，执行set/add/replace 命令并把value数据塞到item之后，调用此函数。
* 这个函数的作用比较简单，主要是做一些收尾工作。
*
*/
static void complete_nread_ascii(conn *c) {
assert(c != NULL);
item *it = c->item;
int comm = c->cmd;
enum store_item_type ret;
pthread_mutex_lock(&c->thread->stats.mutex);
c->thread->stats.slab_stats[it->slabs_clsid].set_cmds++;
pthread_mutex_unlock(&c->thread->stats.mutex);
if (strncmp(ITEM_data(it) + it->nbytes - 2, "\r\n", 2) != 0) {
out_string(c, "CLIENT_ERROR bad data chunk");
} else {
ret = store_item(it, comm, c);
}
switch (ret) {
case STORED:
out_string(c, "STORED");
break;
//省略其它
default:
out_string(c, "SERVER_ERROR Unhandled storage type.");
}
}
//释放引用，注意仅仅是一个释放引用的逻辑，不一定把内存空间给释放掉
//具体是否要把内存空间释放，说见item_remove和do_item_remove函数。而在此处，
//一般都只是释放引用而已。
item_remove(c->item); /* release the c->item reference */
c->item = 0;
}
//重置命令处理
static void reset_cmd_handler(conn *c) {
c->cmd = -1;
c->substate = bin_no_state;
if(c->item != NULL) {
item_remove(c->item);
c->item = NULL;
}
conn_shrink(c);
/**
不知道你有没有在下面这个地方困惑过。。反正我是纠结了很久。。。
这个c->rbytes到底什么时候开始不为0了？为0的话，怎么执行这次的命令？
回顾一下我们是怎么会调用到reset_cmd_handler这个地方：
1）主线程监听到listen fd有连接上来，进入drive_machine的conn_listen状态，
然后accept连接得到client fd，再dispatch_conn_new把client fd丢给某个worker线程
2）某个worker线程收到主线程丢过来的client fd之后，把它加到那个worker线程自己的
event_base，然后注册event_handler（event_handler主要是调drive_machine）作为事件处理函数，
在注册event_handler的同时，初始化了一个conn对象作为drive_machine的参数，
而这个对象中的rbytes为0。
3）当worker线程监听的client fd第一次有命令请求过来时（注意是第一次），例如set key 0 0 4\r\n，
worker线程的收到通知，然后陷入了event_handler再到drive_machine中去。。
而此时，传过来的conn* c，c->state 为conn_new_cmd，而c->rbytes确实为0！！
（再次强调是第一次有命令请求过来时）
就在这个时候就进入reset_cmd_handler，当前你看到的这个地方了。继续分析之后做了些啥：
4）第3）点得知，c->rbytes由此确实为0，所以在这种情况，必然会进入下面的else分支，
状态机进入conn_waiting状态。。。。
5）进入conn_waiting状态做了啥？就是把连接状态由conn_waiting变成conn_read，然后stop = true，退出
状态机。没错，退出状态机了！结束本次event_handler了！这就是比较纠结之处，这次命令请求触发的
event_handler居然只做了把状态由conn_new_cmd变成conn_read，然后再等待下次事件通知。
（详见conn_waiting分支代码）
6）那刚才那个命令请求怎么办？压根没有去读？例如set key 0 0 4\r\n这个命令的实质作用被忽略了吗？
其实没有。。原因是libevent默认的是水平触发，也就是说，这个命令还没被读，下次继续触发。。。
下次event_base会因为刚才那个命令再触发通知告诉worker线程，再次进入drive_machine，只是此时
c->state是conn_read状态，conn_read分支才真正把这个命令执行！
也就是说，当worker线程监听的client fd "第一次"有命令过来的时候，会触发两次event_base的通知！！
*/
//这个rbytes大于0的情况，是当一次event中包含多个命令，
//或者说多个\r\n时候，程序执行到第二个及以后命令的时候出现。
if (c->rbytes > 0) {
conn_set_state(c, conn_parse_cmd);
} else {
conn_set_state(c, c
onn_waiting);
}
}
enum store_item_type do_store_item(item *it, int comm, conn *c, const uint32_t hv) {
char *key = ITEM_key(it);
item *old_it = do_item_get(key, it->nkey, hv); //拿出旧的item
enum store_item_type stored = NOT_STORED;
item *new_it = NULL;
int flags;
if (old_it != NULL && comm == NREAD_ADD) {
do_item_update(old_it); //更新item信息，其实主要是更新最近使用信息，即lru链表，。
} else if (!old_it && (comm == NREAD_REPLACE
|| comm == NREAD_APPEND || comm == NREAD_PREPEND))
{
} else if (comm == NREAD_CAS) { //省略
} else {
if (comm == NREAD_APPEND || comm == NREAD_PREPEND) {
if (ITEM_get_cas(it) != 0) {
// CAS much be equal
if (ITEM_get_cas(it) != ITEM_get_cas(old_it)) {
stored = EXISTS;
}
}
if (stored == NOT_STORED) {
flags = (int) strtol(ITEM_suffix(old_it), (char **) NULL, 10);
new_it = do_item_alloc(key, it->nkey, flags, old_it->exptime, it->nbytes + old_it->nbytes - 2 /* CRLF */, hv);
if (new_it == NULL) {
if (old_it != NULL)
do_item_remove(old_it);
return NOT_STORED;
}
if (comm == NREAD_APPEND) {
memcpy(ITEM_data(new_it), ITEM_data(old_it), old_it->nbytes);
memcpy(ITEM_data(new_it) + old_it->nbytes - 2 /* CRLF */, ITEM_data(it), it->nbytes);
} else {
memcpy(ITEM_data(new_it), ITEM_data(it), it->nbytes);
memcpy(ITEM_data(new_it) + it->nbytes - 2 /* CRLF */, ITEM_data(old_it), old_it->nbytes);
}
it = new_it;
}
}
//SET 命令会直接跑来这里，不仔细看还真不知道 -_-||
/**
会跑来这里的，NOT_STORED的都是还没执行"link"操作的情况。
像NREAD_APPEND这些命令都是有link过的。
至于什么是link，具体往下看。
*/
if (stored == NOT_STORED) {
if (old_it != NULL)
/**
如果要SET 的key已经存在，则用新的item覆盖新的。
详见thread::item_replace和items::do_item_replace
*/
item_replace(old_it, it, hv);
else
/**
如果要SET 的不存在，则把item链接起来，这链接主要是做了一些关于这个item杂七
杂八的工作，其实比较重要的两点：
1）把item放到hash table ，作用就是为了能够很快通过key拿到item啦。
2）插入到lru链表
详见items::do_item_link
*/
do_item_link(it, hv);
c->cas = ITEM_get_cas(it);
stored = STORED;
}
}
if (old_it != NULL)
do_item_remove(old_it); /* release our reference */
if (new_it != NULL)
do_item_remove(new_it);
if (stored == STORED) {
c->cas = ITEM_get_cas(it);
}
return stored;
}
static void process_update_command(conn *c, token_t *tokens, const size_t ntokens, int comm, bool handle_cas) {
char *key;
size_t nkey;
unsigned int flags;
int32_t exptime_int = 0;
time_t exptime;
int vlen;
uint64_t req_cas_id=0;
item *it;
assert(c != NULL);
set_noreply_maybe(c, tokens, ntokens);
if (tokens[KEY_TOKEN].length > KEY_MAX_LENGTH) {
out_string(c, "CLIENT_ERROR bad command line format"); //key过长，out_string函数的作用是输出响应，
//详见out_string定义处
return;
}
key = tokens[KEY_TOKEN].value; //键名
nkey = tokens[KEY_TOKEN].length; //键长度
if (! (safe_strtoul(tokens[2].value, (uint32_t *)&flags)
&& safe_strtol(tokens[3].value, &exptime_int)
&& safe_strtol(tokens[4].value, (int32_t *)&vlen))) {
out_string(c, "CLIENT_ERROR bad command line format");
return;
}
exptime = exptime_int;
if (exptime < 0)
exptime = REALTIME_MAXDELTA + 1;
if (handle_cas) {
if (!safe_strtoull(tokens[5].value, &req_cas_id)) {
out_string(c, "CLIENT_ERROR bad command line format");
return;
}
}
vlen += 2;
if (vlen < 0 || vlen - 2 < 0) {
out_string(c, "CLIENT_ERROR bad command line format");
return;
}
if (settings.detail_enabled) {
stats_prefix_record_set(key, nkey);
}
it = item_alloc(key, nkey, flags, realtime(exptime), vlen); //在这里执行内存分配工作。详见item_alloc
if (it == 0) {
//略
return;
}
ITEM_set_cas(it, req_cas_id);
c->item = it; //将item指针指向分配的item空间
c->ritem = ITEM_data(it); //将 ritem 指向 it->data中要存放 value 的位置
c->rlbytes = it->nbytes; //data的大小
c->cmd = comm; //命令类型
conn_set_state(c, conn_nread); //继续调用状态机，执行命令的另一半工作。
}
/**
这里就是对命令的解析和执行了，准确来说，这里只是执行了命令的一半，
然后根据命令类型再次改变conn_state使程序再次进入状态机，完成命令的
另一半工作
command此时的指针值等于conn的rcurr
*/
static void process_command(conn *c, char *command) {
token_t tokens[MAX_TOKENS];
size_t ntokens;
int comm; //命令类型
assert(c != NULL);
MEMCACHED_PROCESS_COMMAND_START(c->sfd, c->rcurr, c->rbytes);
if (settings.verbose > 1)
fprintf(stderr, "<%d %s\n", c->sfd, command);
c->msgcurr = 0;
c->msgused = 0;
c->iovused = 0;
if (add_msghdr(c) != 0) {
out_of_memory(c, "SERVER_ERROR out of memory preparing response");
return;
}
/**
下面这个tokenize_command是一个词法分析，把command分解成一个个token
*/
ntokens = tokenize_command(command, tokens, MAX_TOKENS);
//下面是对上面分解出来的token再进行语法分析，解析命令，下面的comm变量为最终解析出来命令类型
if (ntokens >= 3 &&
((strcmp(tokens[COMMAND_TOKEN].value, "get") == 0) ||
(strcmp(tokens[COMMAND_TOKEN].value, "bget") == 0))) {
process_get_command(c, tokens, ntokens, false);
} else if ((ntokens == 6 || ntokens == 7) &&xx//略
//add/set/replace/prepend/append为“更新”命令，调用同一个函数执行命令。详见process_update_command定义处
process_update_command(c, tokens, ntokens, comm, false);
} else if ((ntokens == 7 || ntokens == 8) && (strcmp(tokens[COMMAND_TOKEN].value, "cas") == 0 && (comm = NREAD_CAS))) {
process_update_command(c, tokens, ntokens, comm, true);
} else if ((ntokens == 4 || ntokens == 5) && (strcmp(tokens[COMMAND_TOKEN].value, "incr") == 0)) {
process_arithmetic_command(c, tokens, ntokens, 1);
} else if (ntokens >= 3 && (strcmp(tokens[COMMAND_TOKEN].value, "gets") == 0)) {
//执行get 命令
process_get_command(c, tokens, ntokens, true);
} else if ((ntokens == 4 || ntokens == 5) && (strcmp(tokens[COMMAND_TOKEN].value, "decr") == 0)) {
process_arithmetic_command(c, tokens, ntokens, 0);
} else if (ntokens >= 3 && ntokens <= 5 && (strcmp(tokens[COMMAND_TOKEN].value, "delete") == 0)) {
//执行delete 删除命令
process_delete_command(c, tokens, ntokens);
}elseif{//省略其它命令。。。
}
return;
}
/*
* if we have a complete line in the buffer, process it.
*/
static int try_read_command(conn *c) {
assert(c != NULL);
assert(c->rcurr <= (c->rbuf + c->rsize));
assert(c->rbytes > 0);
//省略掉UDP和二进制协议的逻辑
if (c->protocol == binary_prot) {
} else {
char *el, *cont;
if (c->rbytes == 0) //读buffer没有待解析的数据
return 0;
el = memchr(c->rcurr, ‘\n‘, c->rbytes); //找第一个命令的末尾，即换行符
if (!el) {
if (c->rbytes > 1024) {
char *ptr = c->rcurr;
while (*ptr == ‘ ‘) { /* ignore leading whitespaces */
++ptr;
}
if (ptr - c->rcurr > 100 ||
(strncmp(ptr, "get ", 4) && strncmp(ptr, "gets ", 5))) {
conn_set_state(c, conn_closing);
return 1;
}
}
/*
如果没有找到换行符，则说明读到的数据还不足以成为一个完整的命令，
返回0
*/
return 0;
}
cont = el + 1; //下一个命令的开头
/*
下面这个if的作用是把el指向当前命令最后一个有效字符的下一个字符，即\r
目的是为了在命令后面插上一个\0，字符串结束符。
例如 GET abc\r\n******，变成GET abc\0\n*****，这样以后读出的字符串就是一个命令。
*/
if ((el - c->rcurr) > 1 && *(el - 1) == ‘\r‘) {
el--;
}
*el = ‘\0‘;
assert(cont <= (c->rcurr + c->rbytes));
c->last_cmd_time = current_time;
process_command(c, c->rcurr); //执行命令。分析详见process_command
//当前命令执行完之后，把当前指针rcurr指向下一个命令的开头，并调用rbytes（剩余未处理字节数大小）
//逻辑上相当于把已处理的命令去掉。
c->rbytes -= (cont - c->rcurr);
c->rcurr = cont;
assert(c->rcurr <= (c->rbuf + c->rsize));
}
return 1;
}
static enum try_read_result try_read_network(conn *c) {
enum try_read_result gotdata = READ_NO_DATA_RECEIVED;
int res;
int num_allocs = 0;
assert(c != NULL);
if (c->rcurr != c->rbuf) {
if (c->rbytes != 0) /* otherwise there‘s nothing to copy */
memmove(c->rbuf, c->rcurr, c->rbytes);
c->rcurr = c->rbuf;
}
while (1) {
if (c->rbytes >= c->rsize) {//读buffer空间扩充
if (num_allocs == 4) {
return gotdata;
}
++num_allocs;
char *new_rbuf = realloc(c->rbuf, c->rsize * 2);
if (!new_rbuf) {
//失败的情况，省略
}
c->rcurr = c->rbuf = new_rbuf;
c->rsize *= 2;
}
int avail = c->rsize - c->rbytes; //读buffer的空间还剩余多少大小可以用
res = read(c->sfd, c->rbuf + c->rbytes, avail); //往剩下的可用的地方里塞
if (res > 0) {
pthread_mutex_lock(&c->thread->stats.mutex);
c->thread->stats.bytes_read += res;
pthread_mutex_unlock(&c->thread->stats.mutex);
gotdata = READ_DATA_RECEIVED;
/**
rbytes是当前指针rcurr至读buffer末尾的数据大小，这里可简单地理解为对rbytes的初始化。
*/
c->rbytes += res;
if (res == avail) { //可能还没读完，此时读buffer可用空间满了，那么下次循环会进行读buffer空间扩充
continue;
} else {
break; //socket的可读数据都读完了
}
}
if (res == 0) {
return READ_ERROR;
}
if (res == -1) {
if (errno == EAGAIN || errno == EWOULDBLOCK) {
break;
}
return READ_ERROR;
}
}
return gotdata;
}
/**
通过状态机的方式处理网络请求/命令，后面的代码可以看到，
实质这里是根据
1）不同的conn连接对象，包括来自主线程的监听listen fd的连接或来自worker线程监听的client fd的连接
2）或者说是conn连接不同的状态，例如主线程监听listen fd连接通常是conn_listenning状态，
而worker线程监听的client fd的连接可能是conn_new_cmd，conn_read等状态
来进行不同的业务处理
*/
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循环里面有一个巨大的switch case，根据连接对象 conn当前
的连接状态conn_state，进入不同的case，而每个case可能会改变conn的连接状态，
也就是说在这个while+switch中，conn会不断的发生状态转移，最后被分发到合适的case上作处理。
可以理解为，这里是一个有向图，每个case是一个顶点，有些case通过改变conn对象的连接状态让程序在
下一次循环中进入另一个case，几次循环后程序最终进入到“无出度的顶点”然后结束状态机，
这里的无出度的顶点就是带设置stop=true的case分支
*/
while (!stop) {
switch(c->state) {
case conn_listening: //此case只有当listen fd有事件到达后触发主线程执行
sfd = accept(c->sfd, (struct sockaddr *)&addr, &addrlen); //accept，得到client fd
if (sfd == -1) {
} else {
/**
accept成功后，调用dispatch_conn_new，把client fd交给 worker线程处理
必须注意dispatch_conn_new 函数第二个参数：init_state，也就是
创建连接对象的初始化状态，通过主线程分发给worker线程的client fd，最终
建立的连接对象初始化状态为conn_new_cmd （当然这里只说的是TCP socket的情况，UDP socket暂不作分析）
*/
dispatch_conn_new(sfd, conn_new_cmd, EV_READ | EV_PERSIST,
DATA_BUFFER_SIZE, tcp_transport);
}
stop = true;
break;
case conn_waiting: //等待数据
if (!update_event(c, EV_READ | EV_PERSIST)) {
if (settings.verbose > 0)
fprintf(stderr, "Couldn‘t update event\n");
conn_set_state(c, conn_closing);
break;
}
conn_set_state(c, conn_read);
stop = true;
break;
case conn_read: //执行读数据
res = IS_UDP(c->transport) ? try_read_udp(c) : try_read_network(c); //从网络上读取数据
switch (res) {
case READ_NO_DATA_RECEIVED:
conn_set_state(c, conn_waiting); //没有数据再继续等待
break;
case READ_DATA_RECEIVED: //成功接收数据则进入conn_parse_cmd分支，解析命令
conn_set_state(c, conn_parse_cmd);
break;
case READ_ERROR:
conn_set_state(c, conn_closing);
break;
case READ_MEMORY_ERROR: /* Failed to allocate more memory */
/* State already set by try_read_network */
break;
}
break;
case conn_parse_cmd :
/**
try_read_network后，到达conn_parse_cmd状态，但try_read_network并不确保每次到达
的数据都足够一个完整的cmd（ascii协议情况下往往是没有"\r\n"，即回车换行），
所以下面的try_read_command之所以叫try就是这个原因，
当读到的数据还不够成为一个cmd的时候，返回0，conn继续进入conn_waiting状态等待更多的数据到达。
*/
if (try_read_command(c) == 0) {
/* wee need more data! */
conn_set_state(c, conn_waiting);
}
break;
case conn_new_cmd:
/* Only process nreqs at a time to avoid starving other
connections */
/*
这里的reqs是请求的意思，其实叫“命令”更准确。一次event发生，有可能包含多个命令，
从client fd里面read到的一次数据，不能保证这个数据只是包含一个命令，有可能是多个
命令数据堆在一起的一次事件通知。这个nreqs是用来控制一次event最多能处理多少个命令。
*/
--nreqs;
if (nreqs >= 0) {
/**
准备执行命令。为什么叫reset cmd，reset_cmd_handler其实做了一些解析执行命令之前
的初始化动下一个，都会重新进入这个case作。而像上面说的，一次event有可能有多个命令，每执行一个命令，如果还有
conn_new_cmd，reset一下再执行下一个命令。
*/
reset_cmd_handler(c);
} else {
//省略
stop = true;
}
break;
case conn_nread:
/**
由process_update_command执行后进入此状态，process_update_command函数只执行了add/set/replace 等命令的一半，
剩下的一半由这里完成。
在这插一下memcached的命令解析协议，add/set/replace等这种写类型的命令，分为两块，或者说要有两次的“回车”，
如：
1)set key 0 0 4\r\n
2)haha\r\n
第1)行是命令，第2)行是数据块。
例如如果是上面的set命令，process_update_command只完成了第1)行，分配了item空间，但还没有把value塞到对应的
item中去。因此，在这一半要完成的动作就是把第2)行代表value的数据读出来，塞到刚拿到的item空间中去
*/
/*
下面的rlbytes字段表示要读的value数据还剩下多少字节
如果是第一次由process_update_command进入到此，rlbytes此时在process_update_command中被初始化为item->nbytes，
即value的总字节数，由第1)行命令中声明，即上面例子第1)行的"4"
*/
if (c->rlbytes == 0) {
/**
如果要读value数据的都读完了，就调用complete_nread完成收尾工作，程序会跟着complete_nread进入下一个
状态。所以执行完complete_nread会break;
*/
complete_nread(c);
break;
}
//如果还有数据没读完，继续往下执行。可知，下面的动作就是继续从buffer中读value数据往item中的data的value位置塞。
/* Check if rbytes < 0, to prevent crash */
if (c->rlbytes < 0) {
if (settings.verbose) {
fprintf(stderr, "Invalid rlbytes to read: len %d\n", c->rlbytes);
}
conn_set_state(c, conn_closing);
break;
}
/* first check if we have leftovers in the conn_read buffer */
if (c->rbytes > 0) {
/**
取rbytes与rlbytes中最小的值。
为啥？
因为这里我们的目的是剩下的还没读的value的字节，而rlbytes代表的是还剩下的字节数
如果rlbytes比rbytes小，只读rlbytes长度就够了，rbytes中多出来的部分不是我们这个时候想要的
如果rbytes比rlbytes小，即使你要rlbytes这么多，但buffer中没有这么多给你读。
*/
int tocopy = c->rbytes > c->rlbytes ? c->rlbytes : c->rbytes;
if (c->ritem != c->rcurr) {
memmove(c->ritem, c->rcurr, tocopy); //往分配的item中塞，即为key设置value的过程
}
c->ritem += tocopy;
c->rlbytes -= tocopy;
c->rcurr += tocopy;
c->rbytes -= tocopy;
if (c->rlbytes == 0) {
break;
}
}
//这里往往是我们先前读到buffer的数据还没足够的情况下，从socket中读。
/* now try reading from the socket */
res = read(c->sfd, c->ritem, c->rlbytes);//往分配的item中塞，即为key设置value的过程
if (res > 0) {
pthread_mutex_lock(&c->thread->stats.mutex);
c->thread->stats.bytes_read += res;
pthread_mutex_unlock(&c->thread->stats.mutex);
if (c->rcurr == c->ritem) {
c->rcurr += res;
}
c->ritem += res;
c->rlbytes -= res;
break;
}
if (res == 0) { /* end of stream */
conn_set_state(c, conn_closing);
break;
}
if (res == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
if (!update_event(c, EV_READ | EV_PERSIST)) {
if (settings.verbose > 0)
fprintf(stderr, "Couldn‘t update event\n");
conn_set_state(c, conn_closing);
break;
}
stop = true;
break;
}
/* otherwise we have a real error, on which we close the connection */
if (settings.verbose > 0) {
}
conn_set_state(c, conn_closing);
break;
case conn_swallow:
//省略
conn_set_state(c, conn_closing);
break;
case conn_write:
if (c->iovused == 0 || (IS_UDP(c->transport) && c->iovused == 1)) {
if (add_iov(c, c->wcurr, c->wbytes) != 0) {
}
}
/* fall through... */ //直接进入conn_mwrite分支
case conn_mwrite:
if (IS_UDP(c->transport) && c->msgcurr == 0 && build_udp_headers(c) != 0) {
if (settings.verbose > 0)
fprintf(stderr, "Failed to build UDP headers\n");
conn_set_state(c, conn_closing);
break;
}
switch (transmit(c)) { //执行transmit发送数据到客户端
case TRANSMIT_COMPLETE:
if (c->state == conn_mwrite) {
conn_release_items(c);
if(c->protocol == binary_prot) {
conn_set_state(c, c->write_and_go);
} else {
conn_set_state(c, conn_new_cmd); //重新回到conn_new_cmd分支等待新命令
}
} else if (c->state == conn_write) {
if (c->write_and_free) {
free(c->write_and_free);
c->write_and_free = 0;
}
conn_set_state(c, c->write_and_go);
} else {
if (settings.verbose > 0)
fprintf(stderr, "Unexpected state %d\n", c->state);
conn_set_state(c, conn_closing);
}
break;
case TRANSMIT_INCOMPLETE:
case TRANSMIT_HARD_ERROR:
break; /* Continue in state machine. */
case TRANSMIT_SOFT_ERROR:
stop = true;
break;
}
break;
case conn_closing:
if (IS_UDP(c->transport))
conn_cleanup(c);
else
conn_close(c);
stop = true;
break;
case conn_closed:
/* This only happens if dormando is an idiot. */
abort();
break;
case conn_max_state:
assert(false);
break;
}
}
return;
}
//事件处理器主要调用drive_machine状态机执行事件处理
void event_handler(const int fd, const short which, void *arg) {
conn *c;
c = (conn *)arg;
assert(c != NULL);
c->which = which;
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(c); //调用drive_machine处理事件发生后的业务逻辑。
return;
}
//创建socket
static int new_socket(struct addrinfo *ai) {
int sfd;
int flags;
if ((sfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol)) == -1) {
return -1;
}
if ((flags = fcntl(sfd, F_GETFL, 0)) < 0 ||
fcntl(sfd, F_SETFL, flags | O_NONBLOCK) < 0) {
perror("setting O_NONBLOCK");
close(sfd);
return -1;
}
return sfd;
}
static int server_sockets(int port, enum network_transport transport,
FILE *portnumber_file) {
if (settings.inter == NULL) { //如果没有指定ip
return server_socket(settings.inter, port, transport, portnumber_file);
} else {
//省略指定的情况
return ret;
}
}
//main函数
int main (int argc, char **argv) {
//省略一些变量定义，下面使用到时会说明
settings_init(); //初始化配置
setbuf(stderr, NULL);
//memcached启动时指定的启动参数配置，在此省略
while (-1 != (c = getopt(argc, argv, xxx
}
if (hash_init(hash_type) != 0) { //哈希算法初始化
fprintf(stderr, "Failed to initialize hash_algorithm!\n");
exit(EX_USAGE);
}
//身份验证的代码
if (getuid() == 0 || geteuid() == 0) {
}
//以常驻进程方式运行
if (do_daemonize) {
if (daemonize(maxcore, settings.verbose) == -1) {
}
}
main_base = event_init(); //全局的main_base变量
stats_init(); //初始化全局统计
assoc_init(settings.hashpower_init); //初始化哈希表
conn_init(); //初始化连接对象，配置
slabs_init(settings.maxbytes, settings.factor, preallocate); //初始化slabs，这里会对一些内存管理进行初始化
//初始化主线程，参数是worker线程个数，和当前主线程的event_base
thread_init(settings.num_threads, main_base);
if (start_assoc_maintenance_thread() == -1) {//启动哈希表维护线程，详见assoc::start_assoc_maintenance_thread
exit(EXIT_FAILURE);
}
/**
如果开启了slab可重分配，则启动slab维护线程
注意slab维护线程（下面简称s）与哈希表维护线程（下面简称哈）逻辑上不一样的地方：
s是只要用户开启了slab_reassign，那么启动memcached服务的时候这个线程就同时启动的
而哈虽然一开始就启动了，但是处理睡眠态，在需要的时候，memcached才发送信息唤醒。
详见assoc::start_assoc_maintenance_thread和slabs::start_slab_maintenance_thread
*/
if (settings.slab_reassign &&
start_slab_maintenance_thread() == -1) {
exit(EXIT_FAILURE);
}
init_lru_crawler(); //初始化item爬虫
//这里省略unix socket监听方式和UDP的代码
/*
睡眠一下，只是提供一定的时候让socket打开而已
*/
usleep(1000);
if (stats.curr_conns + stats.reserved_fds >= settings.maxconns - 1) {
fprintf(stderr, "Maxconns setting is too low, use -c to increase.\n");
exit(EXIT_FAILURE);
}
if (pid_file != NULL) {
save_pid(pid_file); //创建pid文件
}
drop_privileges();
//进入事件循环
if (event_base_loop(main_base, 0) != 0) {
retval = EXIT_FAILURE;
}
stop_assoc_maintenance_thread(); //进程退出之前停止哈希表维护线程
//进程退出的收尾工作
return retval;
}

标签：

原文地址：http://www.cnblogs.com/guolanzhu/p/5850130.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行