你好，我是華仔。今天這期“特別放送”，我想和你聊聊如何高效地學習開源專案，一方面澄清開源專案學習過程中的幾個誤區，另一方面談談我自己具體實踐時的一套方法論。
得益於開源運動的蓬勃發展，眾多技術頂尖的公司、團隊或者個人通過開源的方式向技術社群貢獻了許多優秀的開源專案，一方面大大促進了整體技術的發展，另一方面大大減輕了中小公司和團隊在技術方面的投入壓力，讓團隊能夠更加聚焦於業務。
開源專案對團隊和業務有很大好處，但對於技術人員來說，如果只是簡單的採取“拿來主義”，那就變成一個陷阱：看似很快的用開源專案實現了需求，但自己的技術水平並沒有什麼提升；甚至可能出現看起來用了很多開源專案，知道很多專案名稱，但技術水平止步不前的窘境。
因此，對於開源專案，不能簡單的採取“拿來主義”，而要比較深入的去學習開源專案，做到“知其然，知其所以然”，一方面是為了更好地應用這些開源專案，另一方面也是為了通過學習優秀的開源專案來提升自己的能力。
很多技術同學確實也想深入學習一些業界成熟和優秀的開源專案，例如 Nginx、Redis、Netty 等，但是在具體實踐的時候，常常因為一些不正確的觀點而誤入歧途，例如：
只有開發這些開源專案的人才能真正理解，我沒法參與這個專案開發，因此我很難深入理解。
我的專案沒有用 Redis，不用的話很難深入理解。
資料結構和演算法很重要，所以我只要研究其資料結構和演算法就夠了，例如 Nginx 用的紅黑樹。
“Talk is cheap, show me the code”，一頭扎進原始碼逐行閱讀。
這些觀點要麼讓自己望而生畏從而輕易放棄，要麼讓自己浪費大量時間而沒有多大收穫。那究竟要怎樣做才是正確的呢？下面我結合自己的經驗談談我對如何學習開源專案的看法。
- 首先，需要樹立正確的觀念：不管你是什麼身份，都可以從開源專案中學到很多東西。
例如，要理解 Redis 的網路模型，我們不需要成為 Redis 的開發者，也不需要一定要用到 Redis，只要具備一定的網路程式設計基礎，再通過閱讀 Redis 的原始碼，都可以學習 Redis 這種單程式的 Reactor 模型。
- 其次，不要只盯著資料結構和演算法，事實上這兩點在學習開源專案的時候並沒有那麼重要。
例如，Nginx 使用紅黑樹來管理定時器，對於絕大部分人來說，只要知道這點就夠了，並不需要去研究 Nginx 實現紅黑樹的原始碼是如何寫的，除非你需要修改這部分，但我認為極少人會有這個需求。
- 第三，採取“自頂向下”的學習方法，原始碼不是第一步，而是最後一步。
不要一上來就去看原始碼，而是要基本掌握了功能、原理、關鍵設計之後再去看原始碼，看原始碼的主要目的是為了學習其程式碼的寫作方式，以及關鍵技術的實現。
例如，Redis 的 RDB 持久化模式“會將當前記憶體中的資料庫快照儲存到磁碟檔案中”，那這裡所謂的“資料庫快照”到底是怎麼做的呢？在 Linux 平臺上其實就是 fork 一個子程式來儲存就可以了；那為何 fork 子程式就生成了資料庫快照了呢？這又和 Linux 的父子程式機制以及 copy-on-write 技術相關了。
通過這種方式，既能夠快速掌握系統設計的關鍵點（Redis 的 RDB 模式），又能夠掌握具體的程式設計技巧（記憶體快照）。
接下來我詳細談談“自頂向下”的學習方法和步驟。
第一步：安裝
很多人看到“安裝”這個步驟都可能會覺得有點不以為然：“不就是對照手冊執行一下命令麼，沒什麼技術含量，用的時候裝一下就可以了”。事實上，安裝步驟遠遠不止這麼簡單，通過具體的安裝過程，你可以獲取到如下一些關鍵資訊：
- 這個系統的依賴元件，而依賴的元件是系統設計和實現的基礎
以 Nginx 為例，原始碼安裝 Nginx 依賴的庫有 pcre、pcre-devel、openssl、openssl-devel、zlib，光從名字上看都能夠了解一些資訊，例如 openssl 可能和 https 有關，zlib 可能和壓縮有關。
再以 Memcache 為例，最大的依賴就是 libevent，而根據 libevent 是一個高效能的網路庫，我們就能大概推測 Memcache 的網路實現應該是 Reactor 模型的。
- 安裝目錄也能夠提供一些使用和執行的基本資訊
例如，Nginx 安裝完成後，目錄如下：
這個目錄提供的資訊有：conf 是存放配置檔案的，logs 是存放日誌的，sbin 是執行程式，但是 html 是什麼呢？這個疑問會促使你繼續去研究和學習。
再來看看 Redis，安裝完成後，目錄下只有一個 bin 目錄，具體如下：
我相信大部分人看到這目錄都會感到有點驚訝：這也太簡單了吧，尤其是與 Nginx 相比！因此也會自然而然的有一些疑問，例如 Redis 如何配置？Redis 日誌儲存在哪裡？這些疑問同樣會促使你繼續去研究和學習，帶著問題去學習效率是最高的。
- 系統提供了哪些工具方便我們使用
同樣以 Redis 為例，你可以看到 redis-benchmark、redis-check-aof 等程式，從名字能夠大概猜出這些工具的基本使用場景，而這些工具在後面故障定位和處理、效能測試等場景可能非常方便。
第二步：執行
安裝完成後，我們需要真正將系統執行起來，執行系統的時候有兩個地方要特別關注：命令列和配置檔案，它們主要提供了兩個非常關鍵的資訊：系統具備哪些能力和系統將會如何執行。這些資訊是我們窺視系統內部執行機制和原理的一扇視窗。
例如，下面是 Memcache 的啟動引數一部分：
通過這幾個啟動引數，你可以獲取如下一些資訊：
Memcache 支援 UNIX socket 通訊和 TCP 通訊。
Memcache 可以指定記憶體大小。
lock memory 看起來和記憶體有關，但具體是什麼意思？配置和不配置有什麼區別麼？
通常情況下，如果我們將每個命令列引數和配置項的作用和原理都全部掌握清楚了的話，基本上對系統已經很熟悉了。我的一個習慣是不管三七二十一，先把所有的配置項全部研究一遍，包括配置項的原理、作用、影響，並且嘗試去修改配置項然後看看系統會有什麼變化。例如，將 Memcache 的“--conn-limit”改為 1 後，檢視多個連線請求時 Memecache 會返回什麼錯誤、記錄什麼日誌等。
第三步：原理研究
完成前兩個步驟後，我們對系統已經有了初步的感覺和理解，此時可以更進一步去研究其原理。其實在研究命令列和配置項的時候已經涉及一部分原理了，但是還不繫統，因此我們要專門針對原理進行系統性的研究。這裡的關鍵就是“系統性”三個字，怎麼才算系統性呢？主要體現在如下幾個方面：
- 關鍵特性的基本實現原理
每個流行的開源專案之所以能夠受到大眾的歡迎，肯定是有一些賣點的，常見的有高效能、高可用、可擴充套件等特性，那到底這些專案是如何做到其所宣稱的那麼牛的呢？這些牛 X 的技術實現就是我們要學習的地方。
例如，Memcache 的高效能具體是怎麼做到的呢？首先是基於 libevent 實現了高效能的網路模型，其次是記憶體管理 Slab Allocator 機制。為了徹底理解 Memcache 的高效能網路模型，我們需要掌握很多知識：多路複用、Linux epoll、Reactor 模型、多執行緒等，通過研究 Memcache 的高效能網路模型，我們能夠學習一個具體的專案中如何將這些東西全部串起來實現了高效能。
再以 React 為例，Virtual DOM 的實現原理是什麼、為何要實現 Virtual DOM、React 是如何構建 Virtual DOM 樹、Virtual DOM 與 DOM 什麼關係等，通過研究學習 Virtual DOM，即使不使用 React，我們也能夠學習如何寫出高效能的前端的程式碼。
- 優缺點對比分析
這是我想特別強調的一點，只有清楚掌握技術方案的優缺點後才算真正的掌握這門技術，也只有掌握了技術方案的優缺點後才能在架構設計的時候做出合理的選擇。
優缺點主要通過對比來分析，即：我們將兩個類似的系統進行對比，看看它們的實現差異，以及不同的實現優缺點都是什麼。
典型的對比有 Memcache 和 Redis，例如（僅舉例說明，實際上對比的點很多），Memcache 用多執行緒，Redis 用單程式，各有什麼優缺點？Memcache 和 Redis 的叢集方式，各有什麼優缺點？
即使是 Redis 自身，我們也可以對比 RDB 和 AOF 兩種模式的優缺點。
在你瞭解了什麼是“系統性”後，我來介紹一下原理研究的手段，主要有三種：
通讀專案的設計文件：例如 Kafka 的設計文件，基本涵蓋了訊息佇列設計的關鍵決策部分；Disruptor 的設計白皮書，詳細的闡述了 Java 單機高效能的設計技巧。
閱讀網上已有的分析文件：通常情況下比較熱門的開源專案，都已經有非常多的分析文件了，我們可以站在前人的基礎上，避免大量的重複投入。但需要注意的是，由於經驗、水平、關注點等差異，不同的人分析的結論可能有差異，甚至有的是錯誤的，因此不能完全參照。一個比較好的方式就是多方對照，也就是說看很多篇分析文件，比較它們的內容共同點和差異點。
Demo 驗證：如果有些技術點難以查到資料，自己又不確定，則可以真正去寫 Demo 進行驗證，通過列印一些日誌或者除錯，能清晰的理解具體的細節。例如，寫一個簡單的分配記憶體程式，然後通過日誌和命令列（jmap、jstat、jstack 等）來檢視 Java 虛擬機器垃圾回收時的具體表現。
第四步：測試
通常情況下，如果你真的準備在實際專案中使用某個開源專案的話，必須進行測試。有的同學可能會說，網上的分析和測試文件很多，直接找一篇看就可以了？如果只是自己學習和研究，這樣做是可以的，因為構建完整的測試用例既需要耗費較多時間，又需要較多機器資源，如果每個專案都這麼做的話，投入成本有點大；但如果是要在實踐專案中使用，必須自己進行測試，因為網上搜的測試結果，不一定與自己的業務場景很契合，如果簡單參考別人的測試結果，很可能會得出錯誤的結論。例如，開源系統的版本不同，測試結果可能差異較大。同樣是 K-V 儲存，別人測試的 value 是 128 位元組，而你的場景 value 都達到了 128k 位元組，兩者的測試結果也差異很大，不能簡單照搬。
測試階段需要特別強調的一點就是：測試一定要在原理研究之後做，不能安裝完成立馬就測試！原因在於如果對系統不熟悉，很可能出現命令列、配置引數沒用對，或者執行模式選擇不對，導致沒有根據業務的特點搭建正確的環境、沒有設計合理的測試用例，從而使得最終的測試結果得出了錯誤結論，誤導了設計決策。曾經有團隊安裝完成 MySQL 5.1 後就進行效能測試，測試結果出來讓人大跌眼鏡，經過定位才發現 innodb_buffer_pool_size 使用的是預設值 8M。
第五步：原始碼研究
原始碼研究的主要目的是學習原理背後的具體編碼如何實現，通過學習這些技巧來提升我們自己的技術能力。例如 Redis 的 RDB 快照、Nginx 的多 Reactor 模型、Disruptor 如何使用 volatile 以及 CAS 來做無鎖設計、Netty 的 Zero-Copy 等，這些技巧都很精巧，掌握後能夠大大提升自己的編碼能力。
通常情況下，不建議通讀所有原始碼，因為想掌握每行程式碼的含義和作用還是非常耗費時間的，尤其是 MySQL、Nginx 這種規模的專案，即使是他們的開發人員，都不一定每個人都掌握了所有程式碼。帶著明確目的去研究原始碼，做到有的放矢，才能事半功倍，這也是原始碼研究要放在最後的原因。
對於一些基礎庫，除了閱讀原始碼外，還可以自己寫個 Demo 呼叫基礎庫完成一些簡單的功能，然後通過除錯來看具體的呼叫棧，通過呼叫棧來理解基礎庫的處理邏輯和過程，這比單純看程式碼去理解邏輯要高效一些。例如，下面是 Netty 4.1 版本的 telnet 伺服器樣例除錯的堆疊，通過堆疊我們可以看到完整的呼叫棧：
時間分配
前面介紹的“自頂向下”5 個步驟，完整執行下來需要花費較長時間，而時間又是大部分技術人員比較稀缺的資源。很多人在學習技術的時候都會反饋說時間不夠，版本進度很緊，很難有大量的時間進行學習，但如果不學習感覺自己又很難提升？面對這種兩難問題，具體該如何做呢？
通常情況下，以上 5 個步驟的前 3 個步驟，不管是已經成為架構師的技術人員，還是立志成為架構師的技術人員，在研究開源專案的時候都必不可少；第四步可以在準備採用開源專案的時候才實施，第五步可以根據你的時間來進行靈活安排。這裡的“靈活安排”不是說省略不去做，而是在自己有一定時間和精力的時候做，因為只有這樣才能真正理解和學到具體的技術。
如果感覺自己時間和精力不夠，與其蜻蜓點水每個開源專案都去簡單瞭解一下，還不如集中精力將一個開源專案研究通透，就算是每個季度只學習一個開源專案，積累幾年後這個數量也是很客觀的；而且一旦你將一個專案研究透以後，再去研究其他類似專案，你會發現自己學習的非常快，因為共性的部分你已經都掌握了，只需要掌握新專案差異的部分即可。