編者按：本文節選自圖靈程序設計叢書 《Kafka權威指南》一書中的部分章節。
起源故事
Kafka 是爲了解決 LinkedIn 數據管道問題應運而生的。它的設計目的是提供一個高性能的消息系統，可以處理多種數據類型，並能夠實時提供純淨且結構化的用戶活動數據和系統度量指標。
數據爲我們所做的每一件事提供了動力。
——Jeff Weiner，LinkedIn CEO
LinkedIn的問題
本章開頭提到過，LinkedIn 有一個數據收集系統和應用程序指標，它使用自定義的收集器和一些開源工具來保存和展示內部數據。除了跟蹤 CPU 使用率和應用性能這些一般性指標外，LinkedIn 還有一個比較複雜的用戶請求跟蹤功能。它使用了監控系統，可以跟蹤單個用戶的請求是如何在內部應用間傳播的。不過監控系統存在很多不足。它使用的是輪詢拉取度量指標的方式，指標之間的時間間隔較長，而且沒有自助服務能力。它使用起來不太方便，很多簡單的任務需要人工介入才能完成，而且一致性較差，同一個度量指標的名字在不同系統裏的叫法不一樣。
與此同時，我們還創建了另一個用於收集用戶活動信息的系統。這是一個 HTTP 服務，前端的服務器會定期連接進來，在上面發佈一些消息（XML 格式）。這些消息文件被轉移到線下進行解析和校對。同樣，這個系統也存在很多不足。XML 文件的格式無法保持一致，而且解析 XML 文件非常耗費計算資源。要想更改所創建的活動類型，需要在前端應用和離線處理程序之間做大量的協調工作。即使是這樣，在更改數據結構時，仍然經常出現系統崩潰現象。而且批處理時間以小時計算，無法用它完成實時的任務。
監控和用戶活動跟蹤無法使用同一個後端服務。監控服務太過笨重，數據格式不適用於活動跟蹤，而且無法在活動跟蹤中使用輪詢拉取模型。另一方面，把跟蹤服務用在度量指標上也過於脆弱，批處理模型不適用於實時的監控和告警。不過，好在數據間存在很多共性，信息（比如特定類型的用戶活動對應用程序性能的影響）之間的關聯度還是很高的。特定類型用戶活動數量的下降說明相關應用程序存在問題，不過批處理的長時間延遲意味着無法對這類問題作出及時的反饋。
最開始，我們調研了一些現成的開源解決方案，希望能夠找到一個系統，可以實時訪問數據，並通過橫向擴展來處理大量的消息。我們使用 ActiveMQ 創建了一個原型系統，但它當時還無法滿足橫向擴展的需求。LinkedIn 不得不使用這種脆弱的解決方案，雖然 ActiveMQ 有很多缺陷會導致 broker 暫停服務。客戶端的連接因此被阻塞，處理用戶請求的能力也受到影響。於是我們最後決定構建自己的基礎設施。
Kafka的誕生
LinkedIn 的開發團隊由 Jay Kreps 領導。Jay Kreps 是 LinkedIn 的首席工程師，之前負責分佈式鍵值存儲系統 Voldemort 的開發。初建團隊成員還包括 Neha Narkhede，不久之後， Jun Rao 也加入了進來。他們一起着手創建一個消息系統，可以同時滿足上述的兩種需求，並且可以在未來進行橫向擴展。他們的主要目標如下：
- 使用推送和拉取模型解耦生產者和消費者；
- 爲消息傳遞系統中的消息提供數據持久化，以便支持多個消費者；
- 通過系統優化實現高吞吐量；
- 系統可以隨着數據流的增長進行橫向擴展。
最後我們看到的這個發佈與訂閱消息系統具有典型的消息系統接口，但從存儲層來看，它更像是一個日誌聚合系統。Kafka 使用 Avro 作爲消息序列化框架，每天高效地處理數十億級別的度量指標和用戶活動跟蹤信息。LinkedIn 已經擁有超過萬億級別的消息使用量（截止到 2015 年 8 月），而且每天仍然需要處理超過千萬億字節的數據。
走向開源
2010 年底，Kafka 作爲開源項目在 GitHub 上發佈。2011 年 7 月，因爲倍受開源社區的關注，它成爲 Apache 軟件基金會的孵化器項目。2012 年 10 月，Kafka 從孵化器項目畢業。從那時起，來自 LinkedIn 內部的開發團隊一直爲 Kafka 提供大力支持，而且吸引了大批來自 LinkedIn 外部的貢獻者和參與者。現在，Kafka 被很多組織用在一些大型的數據管道上。2014 年秋天，Jay Kreps、Neha Narkhede 和 Jun Rao 離開 LinkedIn，創辦了 Confluent。 Confluent 是一個致力於爲企業開發提供支持、爲 Kafka 提供培訓的公司。這兩家公司連同來自開源社區持續增長的貢獻力量，一直在開發和維護 Kafka，讓 Kafka 成爲大數據管道的不二之選。
命名
關於 Kafka 的歷史，人們經常會問到的一個問題就是，Kafka 這個名字是怎麼想出來的，以及這個名字和這個項目之間有着怎樣的聯繫。對於這個問題，Jay Kreps 解釋如下：
我想既然 Kafka 是爲了寫數據而產生的，那麼用作家的名字來命名會顯得更有意義。我在大學時期上過很多文學課程，很喜歡 Franz Kafka。況且，對於開源項目來說，這個名字聽起來很酷。因此，名字和應用本身基本沒有太多聯繫。
圖書簡介：https://www.ituring.com.cn/book/2067
相關閱讀