Redis源码调试的那些坑和折腾，边学边摸索还没完全搞明白

整理自网络技术社区多位开发者的经验分享和讨论,如知乎、CSDN、Stack Overflow 以及一些个人博客上的帖子，具体来源已混合，无法逐一标注）

最开始想调试Redis源码,是因为总觉得光看代码不过瘾，很多细节怎么跑的心里没底，就想动手跟一下，结果这一跟，真是踩了无数坑，折腾了好久，有些地方到现在也没完全整明白，感觉水挺深的。

第一个大坑就是编译环境,我看网上都说用make就行，简单，但我本地机器上直接make，跑是能跑起来，可调试信息总感觉不对，后来才搞懂，得用make noopt才行，那个make默认是带优化选项-O2的，编译器一优化，代码就被重排得亲妈都不认识了，变量可能被优化掉，行号也对不上，你用GDB设断点，它经常乱跳，根本没法单步跟踪，换成make noopt，禁止优化，编译出来的调试信息才是准的，这个点就卡了我小半天，一开始还以为是GDB配置有问题。

环境搞定了,第二个坑是怎么启动和连接，直接./redis-server前台运行，然后另开个终端用redis-cli，这没问题，但你想用GDB附着上去调试，就麻烦了，Redis是事件驱动的，一启动就进入事件循环等着，你根本不知道下一个断点该设在哪儿，后来学乖了，得在main函数或者关键的初始化函数那里先设个断点，比如initServer，让服务端启动后先暂停，然后再让GDB附着上去（用gdb -p <pid>），或者一开始就用GDB启动redis-server，然后在GDB里面run，但这样又有个新问题，redis-cli发命令过来，服务端在GDB里停了，cli那边就超时了，体验很割裂。

然后是最折磨人的部分,就是跟踪命令的执行流程，Redis是单线程的，这好处是不会有并发问题干扰，但坏处是整个流程非常长，函数调用栈很深，比如你发一个最简单的SET key value，从网络读数据开始，到解析命令，找命令表，执行函数，再到写回响应，经过的层级太多了，我试着跟过一次，跟到后面自己都晕了，什么aeMain、aeProcessEvents、readQueryFromClient、processInputBuffer、processCommand、call…… 函数一个套一个，而且里面用了很多函数指针，比如在processCommand里根据命令名找到对应的函数（像setCommand），然后通过c->cmd->proc(c)这样的方式调用，你跟进去的时候一不小心就跟丢了，这种设计很灵活，但对调试新手来说，理解起来有点绕。

内存管理这块也是个迷糊点,Redis自己搞了个zmalloc，说是为了更好的内存控制和碎片管理，但我在调试的时候，有时候想看一个对象（比如一个redisObject）到底占了多少内存，或者哪里发生了内存分配和释放，就特别费劲，因为所有的内存操作都封装在zmalloc和zfree里了，你没法直接看到底层malloc的调用，虽然有办法可以钩子这些函数，但配置起来又很麻烦，有时候感觉内存涨了，但不知道是哪个命令或者哪个数据结构导致的，只能靠猜和打日志，效率很低。

还有数据结构,比如跳跃表（zskiplist）的实现，代码看起来挺精巧的，但调试的时候想直观地看一个跳跃表的结构，比如有多少层，每层的指针指向哪里，就非常困难，GDB的打印能力有限，你得自己写复杂的打印函数，或者靠脑补，哈希表rehash的过程也是，虽然是渐进式的，但真想一步步看它怎么迁移桶的，断点很难设，因为迁移是分散在每次命令请求里的一点点做的，不是集中完成的。

最让我头疼的是和异步机制相关的问题,比如持久化（RDB和AOF），你在调试主流程的时候，突然后台子进程开始fork出去做RDB快照了，或者AOF缓冲区要刷盘了，这时候整个进程的状态会变得非常复杂，特别是fork之后，父子进程共享内存空间，调试起来更是要小心，一不留神就跟错进程了，这部分我基本没敢深入跟，只是看了看大致的函数入口，比如rdbSaveBackground、aofRewriteBackground，里面的细节感觉像黑盒一样。

折腾了这么一圈,感觉对Redis的内部运作是有了个模糊的轮廓，知道了大致的流水线，但离“搞明白”还差得远，很多精妙的设计，比如事件循环的效率、数据结构的细节、内存管理的策略，都只是停留在“知道它是这么做的”层面，至于“为什么这么做”、“有没有更好的办法”，还是云里雾里，可能看源码调试就是这样吧，就是一个不断踩坑、不断摸索、不断发现自己无知的过程，现在我的态度就是，用到哪块，对哪块有疑问，就重点去翻哪块的代码和调试一下，想一次性全搞懂，实在太难了。