說起 Kafka 的第一個突出特定就是“快”，而且是那種變態的“快”。據最新的資料：每天利用 Kafka 處理的訊息超過1萬億條，在峰值時每秒鐘會發布超過百萬條訊息，就算是在記憶體和 CPU 都不高的情況下，Kafka 的速度最高可以達到每秒十萬條資料，並且還能持久化儲存。那麼，Kafka 是如何做到的呢？

分散式訊息系統 Kafka

授權協議：Apache

開發語言：Scala

作業系統：跨平臺

開發廠商：Apache

Github：https://github.com/apache/kafka★6120

Kafka 是一種分散式的，基於釋出/訂閱的訊息系統。原本開發自 LinkedIn，用作 LinkedIn 的活動流（Activity Stream）和運營資料處理管道（Pipeline）的基礎。之後成為 Apache 專案的一部分，主要用於處理活躍的流式資料。

kafka 有如下特性：

● 通過O(1)的磁碟資料結構提供訊息的持久化，這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。

● 高吞吐量：即使是非常普通的硬體kafka也可以支援每秒數十萬的訊息。

● 支援通過kafka伺服器和消費機叢集來分割槽訊息。

● 支援Hadoop並行資料載入。

Kafka 的整體架構非常簡單，是顯式分散式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer 實現 Kafka 註冊的介面，資料從 producer 傳送到broker，broker 承擔一箇中間快取和分發的作用。broker 分發註冊到系統中的consumer。broker 的作用類似於快取，即活躍的資料和離線處理系統之間的快取。

kafka 相關名詞解釋如下：

1、producer：訊息生產者，釋出訊息到 kafka 叢集的終端或服務。

2、broker：kafka 叢集中包含的伺服器。

3、topic：每條釋出到 kafka 叢集的訊息屬於的類別，即 kafka 是面向 topic 的。

4、partition：partition 是物理上的概念，每個 topic 包含一個或多個 partition。kafka 分配的單位是 partition。

5、consumer：從 kafka 叢集中消費訊息的終端或服務。

6、Consumer group：high-level consumer API 中，每個 consumer 都屬於一個 consumer group，每條訊息只能被 consumer group 的一個 Consumer 消費，但可以被多個 consumer group 消費。

7、replica：partition 的副本，保障 partition 的高可用。

8、leader：replica 中的一個角色， producer 和 consumer 只跟 leader 互動。

9、follower：replica 中的一個角色，從 leader 中複製資料。

10、controller：kafka 叢集中的其中一個伺服器，用來進行 leader election 以及 各種 failover。

11、zookeeper：kafka 通過 zookeeper 來儲存叢集的 meta 資訊。

Kafka 有四個核心的 API。客戶端和伺服器端的通訊，是基於簡單，高效能，且與程式語言無關的 TCP 協議。

因為每條訊息都被 append 到該 Partition 中，屬於順序寫磁碟，因此效率非常高（經驗證，順序寫磁碟效率比隨機寫記憶體還要高，這是 Kafka 高吞吐率的一個很重要的保證）。 Kafka 叢集分割槽日誌如下所示：

每個分割槽是一個有序的，不可變的記錄序列，不斷附加到結構化的提交日誌中。每個分割槽中的記錄都被分配一個順序的 id 號，稱為唯一標識分割槽中每個記錄的偏移量。

訊息佇列

比起大多數的訊息系統來說，Kafka 有更好的吞吐量，內建的分割槽，冗餘及容錯性，這讓 Kafka 成為了一個很好的大規模訊息處理應用的解決方案。訊息系統一般吞吐量相對較低，但是需要更小的端到端延時，並嚐嚐依賴於 Kafka 提供的強大的永續性保障。在這個領域，Kafka足以媲美傳統訊息系統，如 ActiveMR 或 RabbitMQ。

行為跟蹤

Kafka 的另一個應用場景是跟蹤使用者瀏覽頁面、搜尋及其他行為，以釋出-訂閱的模式實時記錄到對應的 Topic 裡。那麼這些結果被訂閱者拿到後，就可以做進一步的實時處理，或實時監控，或放到 hadoop 離線資料倉庫裡處理。

元資訊監控

作為操作記錄的監控模組來使用，即彙集記錄一些操作資訊，可以理解為運維性質的資料監控吧。

日誌收集

日誌收集方面，其實開源產品有很多，包括 Scribe、Apache Flume。很多人使用 Kafka 代替日誌聚合（log aggregation）。日誌聚合一般來說是從伺服器上收集日誌檔案，然後放到一個集中的位置（檔案伺服器或 HDFS）進行處理。然而 Kafka 忽略掉檔案的細節，將其更清晰地抽象成一個個日誌或事件的訊息流。這就讓 Kafka 處理過程延遲更低，更容易支援多資料來源和分散式資料處理。比起以日誌為中心的系統比如 Scribe 或者 Flume 來說，Kafka 提供同樣高效的效能和因為複製導致的更高的耐用性保證，以及更低的端到端延遲。

流處理

這個場景可能比較多，也很好理解。儲存收集流資料，以提供之後對接的Storm或其他流式計算框架進行處理。很多使用者會將那些從原始 Topic 來的資料進行階段性處理，彙總，擴充或者以其他的方式轉換到新的 Topic 下再繼續後面的處理。例如一個文章推薦的處理流程，可能是先從 RSS 資料來源中抓取文章的內容，然後將其丟入一個叫做“文章”的topic中；後續操作可能是需要對這個內容進行清理，比如回覆正常資料或者刪除重複資料，最後再將內容匹配的結果返還給使用者。這就在一個獨立的 Topic 之外，產生了一系列的實時資料處理的流程。Strom 和 Samza 是非常著名的實現這種型別資料轉換的框架。

事件源

事件源是一種應用程式設計的方式，該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以儲存大量的日誌資料，這使得它成為一個對這種方式的應用來說絕佳的後臺。比如動態彙總（News feed）。

永續性日誌（commit log）

Kafka 可以為一種外部的永續性日誌的分散式系統提供服務。這種日誌可以在節點間備份資料，併為故障節點資料回覆提供一種重新同步的機制。Kafka中日誌壓縮功能為這種用法提供了條件。在這種用法中，Kafka 類似於 Apache BookKeeper 專案。