Redis编译调试那些细节真是折腾人，但想把精致做到极致感觉快成功了

某技术社区一位开发者分享的博客文章《与Redis源码死磕的七十二小时》）

“Redis编译调试那些细节真是折腾人，但想把精致做到极致感觉快成功了。”这句话简直说到了我的心坎里，前几天，我就是抱着一种“非要看看它里面到底是怎么转的”心态，掉进了编译和调试Redis源码的这个大坑里，说实话，过程真的是一波三折，好几次都想摔键盘，但每次解决一个小问题，那种拨云见日的感觉，又推着我继续往下走。 来源：同上，博客中关于环境搭建的详细记录）

一开始,我以为这事儿很简单，不就是个make命令嘛，我从GitHub上把最新的源码clone下来，兴冲冲地跑进目录，输入make，结果，等着我的不是成功的提示，而是一堆我看不懂的错误信息，我记得最清楚的一个错误是抱怨什么jemalloc找不到，我当时就懵了，这是个啥？后来一通搜索才知道，Redis默认想用一个叫jemalloc的内存分配器，因为它性能更好，但我的Ubuntu系统上没装这个开发库，解决办法倒是不难，要么用sudo apt-get install把它装上，要么在编译的时候加个参数make MALLOC=libc，强制使用系统自带的libc分配器，我选择了后者，心想先让它跑起来再说，就这么一个小小的依赖项，就给了我一个下马威。 来源：博客中关于调试符号和编译选项的纠结部分）

环境问题解决了,编译终于通过了，生成了redis-server可执行文件，但我想要的是能调试，能一步步跟踪代码，于是我很自然地用gdb去加载它，设了断点，一运行，断点是停下了，但一看代码，傻眼了，显示的代码怎么乱七八糟的，根本不是我写的那些c文件里的内容，这才反应过来，默认的编译优化级别可能太高了，编译器为了性能会把代码顺序打乱，导致调试信息对不上，我又得去翻看Makefile，找了好久，才发现需要修改CFLAGS环境变量，加上-O0 -ggdb3这些选项。-O0是关闭优化，-ggdb3是生成给gdb用的详细调试信息，重新编译一遍，这下再用gdb打开，源代码终于清晰地呈现在眼前了，那种感觉，就像擦干净了沾满雾气的眼镜。 来源：博客中描述单步跟踪Redis启动流程的体验）

能调试之后,我就像拿到了游乐园的通行证，开始在里面“瞎逛”，我从main函数开始，一步一步地跟着程序走，看着它如何解析命令行参数，如何初始化服务器配置，如何加载各种各样的模块，最让我印象深刻的是初始化事件循环的那部分代码，Redis是单线程的，但它能处理那么多并发连接，核心就是这个叫ae的事件循环库，我跟着代码，看它如何调用epoll_create，如何将监听套接字注册进去，然后进入那个经典的aeMain循环，不断地aeProcessEvents，虽然这些概念我以前看书都懂，但真正在代码里看到它们是如何一环扣一环地组装起来的，那种感觉是完全不一样的，非常踏实。 来源：博客结尾处作者的感慨）

过程中还有很多小磕绊,比如有时候断点打的位置不对，程序就是不停下来；或者跟踪到一个复杂的函数里，变量太多，看得头晕眼花；又或者想查看一个复杂的数据结构，在gdb里打印出来是一大坨看不明白的地址，每一个问题都需要耐心去解决，去查文档，去试错，正是这些折腾人的细节，让我对Redis的理解不再浮于表面，我不再只是知道它快，而是开始明白它为什么能这么快，它的“精致”体现在哪些代码的细节上，虽然我现在可能只窥探到了它庞大代码库的冰山一角，但这种亲手把玩、亲手调试的过程，让我感觉不是在死记硬背，而是在和它的开发者隔空对话，这个过程确实折腾人，但当我能清晰地跟踪一个SET命令从接收到响应的完整生命周期时，那种“快要把精致做到极致”的感觉就特别强烈，感觉自己也快触摸到那种对代码质量极致追求的边了，这大概就是痛并快乐着吧。