《Kafka技術內幕》作者鄭奇煌：除了學習筆記，也許你還需要流程圖（圖靈訪談）

訪談嘉賓：鄭奇煌，目前就職於杭州某網際網路風控公司。主要專注於大資料、流計算和中介軟體，他希望自己能在技術的路上越走越遠，用技術為社會創造出價值和財富。時常更新個人的部落格：zqhxuyuan.github.io，分享技術學習心得。

訪談實錄：

怎麼對Kafka產生興趣的？

最早，我是通過Zhuang Xiaodan在Github上改造的metaq和Liu Ady的jafka才接觸到Kafka的，但並沒有就此開始做深入的研究。

我在工作當中的主要任務是大資料Spark的開發，一些流任務的處理會借用Kafka。因為業務主要使用了Scala語言開發，我就想著學習一個Scala相關的開源專案。對於我來說，Spark的一些概念很難，於是就選了Kafka作為研究物件，相對來說Kafka的概念還是比較容易理解的。

決定寫《Kafka技術內幕》的原因是什麼？

在學習了很多關於Kafka的優秀資料以後，比如郭俊和李志濤兩位的部落格，我想要更加深入地理解背後的技術原理，所以決定去研究原始碼。斷斷續續看了一個多月，畫了很多圖，就把學習筆記放在了部落格上，從讀者的留言反饋上看，效果還不錯。也許是頭腦一時發熱也許是內心某種追求的激勵，在2016年六七月份的時候，我聯絡了圖靈的編輯王軍花，表達了想要寫書的意思。她還是很鼓勵我寫作的，認為這本書可以填補國內還沒有出版過Kafka相關書籍的空白。當時，除了英文版的Learning Kafka之外，確實沒有其他比較完整的資料了，所以這些更堅定了我寫書的決心。

怎麼定義“在技術上有追求的人”？在技術領域，你有哪些尊敬的人？

我覺得“對技術有追求的人”是能夠利用技術為社會創造出價值和財富的人，他們推動著社會不斷進步。相比這些人，我覺得自己目前還只是“碼農”一枚，在精深技術的道路上還有走很長、很曲折的一段。就我所在的圈子來說，我比較崇（膜）拜Linux之父Linus和賈伯斯這樣的大神~

Kafka是一個什麼樣的工具？擅長做什麼？

最開始的時候，Kafka的定位是一個訊息中介軟體。你把訊息放進去，然後另一個人從裡面取出訊息進行消費，甚至許多不同的人都可以取出相同的訊息。Kafka主要擅長做訊息生產和消費的解耦，即使消費者消費太慢了也不會影響到生產者。它的主要應用有日誌收集、效能度量、網站監控等，比如把日誌、效能資訊等放入Kafka，再通過其他程式對資料進行分析。在最新的版本中，Kafka已經是一個成熟的流式資料處理平臺了，並且也支援外部資料庫匯入匯出到Kafka。

可以說，圖解IT技術是《Kafka技術內幕》的一大特色。書中的圖都是你自己繪製的嗎？使用了哪些繪圖工具？相比文字，繪圖有哪些更高的要求？

書裡面的圖片有近400幅，全部是用Mac的Keynote做的。除了準確表達程式的執行步驟之外，圖片能簡明扼要地呈現。相比文字，用圖片表達，比如不同元件之間的關聯關係或是某一個變數存在的含義，更容易上讀者理解接受。

聽說你在寫作過程中經歷了重重的困難，三改稿件。跟我們分享下遇到的那些困難，以及不斷修改稿件的原因？

第一稿的內容太多，程式碼和圖片都過於詳細，於是在第二稿的時候，我刪掉了一些比較簡單的程式碼和圖片。刪減工作並不是想象的那樣簡單，我必須增加過渡性的鋪墊說明。另外，我是邊研究原始碼邊寫作的，這雖然保證了準確性，卻對寫作有一定的牽制。有些原始碼理解起來比較困難，還得參考相關的測試用例，一點一點啃下官方的英文設計文件。有些地方會有理解不準確，就推翻重寫。比如，在消費組的狀態機這塊，原先畫的流程圖太長，後來自己看起來都有困難，於是重新對這部分進行了拆解。

整體結構上，我一開始設計的順序是生產者、Broker、消費者。原因是，介紹完Broker的資料結構，再理解消費者會比較簡單。後來發現，把生產者和消費者作為客戶端一起分析的話，組織結構會更好，我又把消費者移到了Broker前面。這麼一調整，就要求對消費者中涉及的Broker知識提前做出簡單介紹和修改。

另外，我是利用業餘時間寫作的，進度上確實有點慢。在這裡，也對編輯的工作和耐心表示由衷的感謝，也對網路上一些網友的期待表示感謝，期望本書不會讓你們失望。讀者如果對本書有什麼意見，都可以在圖靈社群提出來。

你是一個“完美主義者”嗎？認可某件事情的標準有哪些？

我覺得，既然選擇了一件事情，就要弄懂它的所有細節，去深究它的實現原理。認可事情的話，我的理解是，你開發出來的某款軟體用起來容易上手。當然這是相對的，你肯定要花時間去深入研究背後的技術，再困難的事情最終也一定都可以解決。

如何看待由程式碼堆疊而來的原始碼分析？

其實，有關原始碼分析的書籍最（被）忌（罵）程式碼太多。在《Kafka技術內幕》這本書裡面，我已經儘量避免大段大段的程式碼，並且沒有直接貼上程式碼段的情況。我建議讀者儘量開啟IDE，跟隨作者一起閱讀原始碼，這種效果是最好的。

其實，我因為本書沒有更多的實戰部分，總覺得有很多遺憾。Linux OpenMessaging規範發起人馮嘉曾建議我在書里加上cruise-control、RocketMQ等內容，我也一開始就打算加上流處理框架與Kafka的整合，但因為書太厚了，只能忍痛割愛。如果再版的話，我會加進相關的內容。

你曾經閱讀過Hadoop、HBase、Storm等的原始碼，對原始碼研究有哪些體會？

最早，我是看蔡斌的《Hadoop技術內幕》入門大資料的，一邊看書一邊研究原始碼，還整理了八百多頁的學習筆記。當時還興沖沖地在微博上釋出了#圖說Hadoop原始碼#（現在連結失效了）的系列文章，作為粉絲的深夜福利（笑）。

enter image description here

分散式檔案系統看完後，我結合《HBase權威指南》學習了分散式儲存框架HBase(0.94)。接著，主要是結合hseagle和fxjwind兩位的部落格研究分散式計算Storm的原始碼。當然，這幾個開源專案看到最後，有些部分是沒有深入進去的，不過總的收穫還是蠻大的。

研究原始碼的時候，我傾向先學習一些優秀的部落格文章，然後結合自己的理解，總結成視覺型的流程圖，還要寫學習筆記。說來也巧，學習完這幾個開源專案，我用到的畫圖工具一般都是系統自帶的工具，比如Window的Office/PlantUML，Ubuntu的LibreOffice，GoogleDoc，Mac的Keynote。

另外，讀原始碼難免會遇到一些難點，這時候可以參考測試用例。開源專案的測試用例一般都是很完整的。還要訂閱官方的郵件，開發人員會很耐心並且及時地解答你的問題。我在測試Kafka Streams時遇到的一些問題，就是Kafka的開發人員幫忙解決的。

請介紹下Kafka的編譯原理？

Kafka首先是一個分散式的訊息佇列，訊息佇列的客戶端包括生產者和消費者。開發者使用Kafka非常簡單，生產者釋出訊息到Kafka的某個主題，消費者從Kafka的指定主題獲取訊息並進行消費。訊息佇列的服務端則是由代理節點、控制器、ZooKeeper等元件構成的，服務端的代理節點是一個叢集，它實現了訊息佇列的的負載均衡、故障容錯、副本複製等功能。

Kafka還是一個流式資料處理平臺（Kafka Streams），提供了一種輕量級的流計算解決方案，部署和使用都非常簡單，直接啟動一個普通的Java應用程式即可。訊息進入Kafka後，應用程式利用這個輕量級的庫通過流計算的運算元，可以做到流式地、實時地訊息處理。

除此之外，為了對接不同的資料來源，Kafka還支援聯結器（Kafka Connect）。這樣，從資料來源產生資料到Kafka、實時處理流式資料、結果資料同步到目標資料來源，都是圍繞著Kafka這個生態系統構建的，我們可以看到Kafka從訊息佇列到流式資料處理平臺，是在一步步成長壯大的。