memcached 源码阅览一

想要快速了解memcached内部原理么？那么赶紧离开本页，这会耽误您的时间。

不知时隔多少时间，今天受了些刺激，在码农路上开始犹豫起来，但是想想自己也没其他本身，就只好放下王者荣耀，重新看看技术内容了。自己看东西比较功利，但总是一开始比较功利，突然被中间说明地方吸引了，就会一层一层的跟下去，这也是有超链接的好处。就先看memcached吧，虽然说起来这东西都十多年了，是个人都能叫出名字，但是用归用，具体的实现公众号之类的也是瞄见无数次，总是浅尝辄止，不能不说工作后是越来越浮躁了。

好了开始阅读代码了，打开Github第一个看到的是timedrun.c，很显然这个和定时相关，这个文件内有个main，程序启动后会fork进程
父进程：捕获子进程事件，并在超过一定时间后向子进程发送term信号，这个时间有程序的argv[1]决定
子进程：execvp一个程序，程序名就是原始启动程序argv[2]中指定的名称（虽然源码中execvp的参数是argv[0]，但这时的argv已经在传入时+2了）

当然这个是一个比较简陋的实现，也只是用在测试中。和memcached的主要功用也没什么大的联系，但是怎么说我是重温了一番学习源码的感觉。

接下有个奇怪的文件叫做memcached_dtrace.d,里面是一些probe打头的定义，文件注释中也说了这是和DTrace相关的，这个东西好像是以前翻过一些资料的在《性能之巅》里也提到过，但是当时就是感觉重新学一套脚本语言分支叉开来太多了，只是草草看了一下。好在DTrace在mac也是默认提供的，这就方便太多了。找到一些好的dtrace资源

前面两个是比较基础的引入例子，后面就是手册了。其实找的个新的感兴趣的东西，最想的就是马上能试着用一下或者跑个结果出来，这个就和某时想干一发一样，如果此时得不到满足，很可能后面就会没兴致或者干脆记不起有这么回事了。当然如果是特别感兴趣的则是愈发得念念不忘的。想起从前各种装系统，最后想搞个黑苹果总是不能成功还试了好几次。废话说完，dtrace是可以直接跟踪程序的，strace只是跟踪程序的系统调用，但是dtrace可以跟踪程序的普通函数调用，而且不用做任何修改。比如一个程序

#include <stdio.h>
#include <unistd.h>
int freq_count() {	
    sleep(1);
    return 0;
}

int main() {
    printf("proc start pid:%d
", getpid());
    for (;;) {
        freq_count();
    }
}

gcc 直接编译后使用如下命令就可以对freq_count这个函数调用进行跟踪

sudo dtrace -n 'pid$target::freq_count:entry { printf("%Y", walltimestamp) }' -p 4423

后面的数字就是程序输出的进程ID，dtrace命令似乎都要sudo才能正常执行否则会有各种权限错误。得到的输出如下：

dtrace: description 'pid$target::freq_count:entry ' matched 1 probe
    CPU     ID                    FUNCTION:NAME
        0 182084                 freq_count:entry 2017 May 27 01:53:33
        0 182084                 freq_count:entry 2017 May 27 01:53:34
        ......

这种模式称为“Function Boundary Tracing (FBT)”就是在函数的出入口进行跟踪，如果要在非函数出入口的一些区段做跟踪可以用“User Statically Defined Tracing (USDT).”。FBT不用修改原有程序就可以进行跟踪，而USDT需要用户把探测点放到自己的程序内部。

很多时候我觉得知道的越多感觉就越好，然而后来发觉也从别人口中得知知识和思考、能力并不是一回事。但是我还是享受这种了解新知的快感，虽然相比于思考的快感是档次低了点，但是我享受。上一年我在手写类似nginx的网络代理，发现内存和耗时上和nginx还是有50%的差距，就是各种猜，用了一些prof工具说是一些函数执行时间太短不会记录和统计，这个相当无语啊。本来一次网络请求就没多少cpu时间，都不统计的话就没办法了。用dtrace，这回我得看看到底是哪里出翔了。

memcached 源码阅览 一

memcached 源码阅览一