讀懂 Redis 源碼，我總結了這 7 點心得

你好，我是 Kaito。

用了這麼久的 Redis，也翻了很多次源碼，經常有人問我到底怎麼讀 Redis 源碼。

一提到讀源碼，很多人都會比較畏懼，認爲讀源碼是高手纔會做的事情。他們可能遇到問題時，會更傾向於去找別人分享的答案。但往往很多時候，自己查到的資料並不能解決所有問題，尤其是比較細節的問題。

從我的實戰經驗來看，遇到這種情況，通常就需要去源碼中尋找答案了，因爲在源碼面前，這些細節會變得「一覽無餘」。

而且我認爲，掌握讀源碼的能力，是從只懂得如何使用 Redis，到精通 Redis 實現原理的成長之路上，必須跨越的門檻。

可是，面對龐大複雜的項目，我們怎樣讀源碼才能更高效呢？

這篇文章我就來和你聊一聊，我讀 Redis 源碼的經驗，以及讀源碼的「通用思路」，希望這些心得可以幫助到你。

01 找到地圖

很多開源項目的源碼，代碼量一般都比較龐大，如果在讀代碼之前，我們沒有制定合理的方法，就一頭扎進去讀代碼，勢必會把自己搞暈。

所以，我在拿到一個項目的代碼之後，並不會馬上着手去讀，而是會先對整個項目結構進行梳理，劃分出項目具體包含的模塊。這樣，我就對整個項目有了一個「宏觀」的瞭解。

讀代碼就好比去一個陌生城市旅行，這個旅途過程充滿着未知。如果在出發之前，我們手裏能有一張地圖，那我們對自己的行程就可以有一個非常清晰的規劃。

我們就知道，如果想要到達目的地，需要從哪裏出發、經過哪些地方、通過什麼方式才能到達，有了地圖就有了行進方向，否則很容易迷失。

因此，提前花一些時間梳理整個項目的「結構和目錄」，對於後面更好地閱讀代碼是非常有必要的。

就拿 Redis 來舉例，在讀 Redis 源碼之前，我們可以先梳理出整個項目的功能模塊，以及每個模塊對應的代碼文件（src 下的代碼結構）：

這樣，有了這張地圖之後，我們再去看代碼的時候，就可以有重點地閱讀了。

02 前置知識準備

在梳理完整個項目結構之後，我們就可以正式進入閱讀環節當中了。不過，在閱讀代碼之前，我們其實還需要預先掌握一些「前置知識」。

因爲一個完整的項目，必然綜合了各個領域的技術知識點，比如數據結構、操作系統、網絡協議、編程語言等，如果我們提前做好一些功課，在讀源碼的過程中就會輕鬆很多。

以下是根據我在閱讀 Redis 書籍和實戰過程中，提取的讀源碼必備前置知識點，你可以參考下：

當然，在閱讀源碼的過程中，我們也可以根據實際問題再去查閱相關資料，但不管怎樣，提前熟悉這些方面的知識，在真正讀代碼時就會省下不少時間。

03 從基礎模塊開始讀

好，有了地圖並掌握了前置知識之後，接下來我們就要進入主題了：讀代碼。

但具體要從哪個地方開始讀起呢？我認爲要先從「最基礎」的模塊開始讀起。

我在前面也分析了，一個完整的項目會劃分很多的功能模塊，但這些模塊並不是孤立的，而很可能是有「依賴」關係的。

比如說，Redis 中的 networking.c 文件，表示處理網絡 IO 的具體實現。而如果我們能在理解事件驅動模塊 ae.c 的基礎上，再去閱讀網絡 IO 模塊，效率就會更高。

那在 Redis 源碼中，哪些是最基礎的模塊呢？

想一下，我們在使用 Redis 時，接觸最頻繁的是哪些功能？

答案是各種數據類型。

一切操作的基礎，其實都是基於這些最常用的數據類型來做的，比如 String、List、Hash、Set、Sorted Set 等。所以，我們就可以從這些基礎模塊開始讀起，也就是從 t_string.c、t_list.c、t_hash.c、t_set.c、t_zset.c 代碼入手。

如果你對 Redis 的數據類型有所瞭解，就會看到這些數據類型在實現時，底層都對應了不同的數據結構。比如，String 的底層是 SDS，List 的底層是 ziplist + quicklist，Hash 底層可能是 ziplist，也可能是哈希表，等等。

由此一來，我們會發現，這些數據結構又是更爲「底層」的模塊，所以我們在閱讀數據類型模塊時，就需要重點聚焦在這些模塊上，也就是 sds.c、ziplist.c、quicklist.c、dict.c、intset.c 文件，而且這些文件都是比較獨立的，閱讀起來就可以更加集中。

這樣，當我們真正掌握了這些「底層數據結構」的實現後，就能更好地理解基於它們實現的各種「數據類型」了。

這些基礎模塊就相當於一座大廈的地基，地基打好了，才能做到高樓聳立。

04 找到核心主線

接着，掌握了數據結構模塊之後，這時我們的重點就需要放在「核心主線」上來了。

在這個階段，我們需要找到一個明確的目標，以這個目標爲主線去讀代碼。因爲讀源碼一個很常見的需求，就是爲了瞭解這個項目最「核心功能」的實現細節，我們只有以此爲目標，找到這條主線去讀代碼，才能達到最終目的。

那麼在讀 Redis 源碼時，什麼纔是它的核心主線呢？這裏我分享一個非常好用的技巧，就是根據「Redis 究竟是怎麼處理客戶端發來的命令的？」 爲主線來梳理。

舉個例子，當我們在執行 SET testkey testval EX 60 這樣一條命令時，就需要搞清楚 Redis 是怎麼執行這條命令的。

也就是要明確，Redis 從收到客戶端請求，到把數據存到 Redis 中、設置過期時間，最後把響應結果返回給客戶端，整個過程的每一個環節，到底是如何處理的。

有了這條主線，我們就有了非常明確的目標，而且沿着這條主線去讀代碼，我們還可以很清晰地把多個模塊「串聯」起來。比如從前面的例子中，我們會看到一條命令的執行，主要包含了這樣幾個階段。

沿着這條主線去讀代碼，我們就可以掌握一條命令的執行全過程。

而且，由於這條主線的代碼邏輯，已經覆蓋了「所有命令」的執行流程，我們下次再去讀其它命令時，比如 SADD，就只需要關注「處理命令」部分的邏輯即可，其它邏輯有 80% 都是相同的。

05 先整體後細節

當然，在閱讀主線代碼的過程中，肯定也會遇到過於「複雜」的函數，第一次在讀這種函數時，很容易就會「陷進去」，導致整個主線代碼的閱讀，無法繼續推進下去。

遇到這種情況其實是很正常的，可這時我們應該怎麼辦呢？

這裏我的做法是，前期讀到這種邏輯時，不要馬上陷入到細節中去，而是要先「抓整體」。

具體來說，對於複雜的函數邏輯，我們剛開始並不需要知道它的每一個細節是如何實現的，而是隻需知道這個函數「大致」做了幾件事情即可。

舉個例子，在執行 HSET 命令時，有一段代碼很複雜，其中包括了很多分支判斷，一次很難讀懂：

那麼，我在讀這段代碼時，就可以先簡化邏輯，把握整體思路：

之後，再瞭解每個分支大致做了哪些事情：

這樣做的好處，一是不會被複雜的細節邏輯搞暈，打擊自己的自信心，二是可以有效避免閱讀的連貫性被打斷，從而能持續推進我們把整個主線邏輯讀完。

所以，這裏的重點就是：先把複雜代碼的主邏輯搞清楚，知道涉及的每個方法完成了什麼事，心裏要先搭建一個簡單的「框架」，等有了框架之後，我們再去給框架填充「細節」。

這樣通過「先整體後細節」的方式，我們就可以不再畏懼代碼中的複雜邏輯。

06 先主線後支線

不過，在閱讀主線代碼的過程中，我們肯定還會遇到各種「支線」邏輯，比如數據過期、替換淘汰、持久化、主從複製等。

其實，在閱讀主線邏輯的時候，我們並不需要去重點關注這些支線，而當整個主線邏輯「清晰」起來之後，我們再去讀這些支線模塊，就會容易很多了。

這時，我們就可以從這些支線中，選取下一個「目標」，帶着這個目標去閱讀，比如說：

有了新的支線目標後，我們依舊可以採用前面提到的「先整體後細節」的思路閱讀相關模塊，這樣下來，整個項目的每個模塊，就可以被「逐一擊破」了。

07 查漏補缺

最後，我們還需要「查漏補缺」。

按照前面提到的方法，基本就可以把整個項目的主要模塊讀得七七八八了，這時我們基本已經對整個項目有了整體的「把控」。

不過，當我們在工作中遇到問題時，很有可能會發現，在當時讀代碼的過程中，有很多並不在意的「細節」被忽略了。

所以這時，我們就可以再帶着「具體問題」出發，聚焦這個問題相關的模塊，再一次去讀源碼。這樣一來，我們就可以填補當時閱讀源碼的「空白區」。

舉個例子，當我們在閱讀 String 底層數據結構 SDS（簡單動態字符串）的實現時，我們會看到當 SDS 需要追加新內容時會進行擴容，而我們之前閱讀這塊代碼時，很有可能只是瞭解到有這樣的邏輯存在，但並沒有在意擴容的相關細節（一次擴容多大）。

所以，當我們在工作中遇到這個細節問題後，就可以把目光聚焦在 SDS 的擴容邏輯上（sds.c 的 sdsMakeRoomFor 函數），而此時我們會發現，當需要申請的新內存小於 1MB 時，Redis 就會翻倍申請內存，否則按 1MB 申請新內存。

採用這個方法進行查漏補缺，我們就可以對整個項目瞭解得更深入、更全面，真正把項目「喫透」。

總結

好了，以上就是我在閱讀 Redis 源碼時的經驗心得，總結一下這 7 個步驟。

1、找到地圖：拿到項目代碼後，提前梳理整個項目結構，知曉整個項目的模塊劃分，以及對應的代碼文件。

2、前置知識準備：提前掌握項目中用到的前置知識，比如數據結構、操作系統原理、網絡協議、網絡 IO 模型、編程語言語法等等。

3、從基礎模塊開始讀：從最底層的基礎模塊開始入手，先掌握了這些模塊，之後基於它們構建的模塊讀起來會更加高效。

4、找到核心主線：找到整個項目中最核心的主線邏輯，以此爲目標，瞭解各模塊爲了完成這個功能，是如何協作和組織的。

5、先整體後細節：對於複雜函數，不要上來就陷入細節，前期閱讀只需瞭解這個函數大致做了什麼事情，建立框架，等搭建起框架之後，再去填充細節。

6、先主線後支線：整個主線邏輯清晰之後，再去延伸閱讀支線邏輯，因爲支線邏輯肯定是服務主線邏輯的，讀完主線後再去讀這些支線，也會變得更簡單。

7、查漏補缺：在工作中遇到具體問題，帶着這些實際的問題出發再次去讀源碼，進行查漏補缺，填補之前讀源碼時沒有注意到的地方。

後記

你可以看到，這篇文章介紹的閱讀源碼的方法，其實並不侷限於讀 Redis 代碼。

這 7 個步驟，可以算是一個的「通用思路」，我也經常用這個思路來讀其它項目的源碼，非常有用，你也可以試試。

另外，我認爲很多人讀源碼覺得難，一是因爲心理上自認爲自己讀不懂，不敢邁步這一步，二是因爲找不到合理的方法，在讀源碼時屢次受挫，最終知難而退。

我在讀源碼時也經歷過這些，這裏再分享一下我的經驗。

1、永遠不要給自己設限：想想看，曾經以爲很多自己做不到的事，在有壓力的情況下，是不是慢慢都做到了，而且發現做得還挺好？學習技術也是一樣，技術是死的，東西就那麼多，一遍不行來兩遍，總有一次能搞懂，所以心態上一定不要先「否定」自己，凡事先邁一小步進去試試看，好的開始就是成功的一半。

2、找到對的學習方法：正所謂「學會學習，再學習」，科學高效的方法，能幫你事半功倍，這篇文章分享的方法論，就是屬於學習方法的範疇，你可以結合自己的實際情況試試看。

希望我的這些經驗和心得，對你有所啓發。

如果你也有自己的閱讀源碼的實踐經驗和方法，歡迎在留言區分享出來，我們一起交流，共同進步~

我是 Kaito，是一個對於技術有思考的資深後端程序員，在我的文章中，我不僅會告訴你一個技術點是什麼，還會告訴你爲什麼這麼做？我還會嘗試把這些思考過程，提煉成通用的方法論，讓你可以應用在其它領域中，做到舉一反三。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Lz7J45jmo3aYAUvg8vStNA

猜你喜歡