Kafka是分散式釋出-訂閱訊息系統。

它最初由LinkedIn公司開發，之後成為Apache專案的一部分。Kafka是一個分散式的，可劃分的，冗餘備份的永續性的日誌服務。它主要用於處理活躍的流式資料。

原文：http://blog.jobbole.com/75328/

為何使用訊息系統

• 解耦

  在專案啟動之初來預測將來專案會碰到什麼需求，是極其困難的。訊息系統在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面。這允許你獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

• 冗餘

  有些情況下，處理資料的過程會失敗。除非資料被持久化，否則將造成丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。許多訊息佇列所採用的"插入-獲取-刪除"正規化中，在把一個訊息從佇列中刪除之前，需要你的處理系統明確的指出該訊息已經被處理完畢，從而確保你的資料被安全的儲存直到你使用完畢。
• 擴充套件性

  因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變程式碼、不需要調節引數。擴充套件就像調大電力按鈕一樣簡單。

• 靈活性 & 峰值處理能力

  在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

• 可恢復性

  系統的一部分元件失效時，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。
• 順序保證

  在大多使用場景下，資料處理的順序都很重要。大部分訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。Kafka保證一個Partition內的訊息的有序性。

• 緩衝

  在任何重要的系統中，都會有需要不同的處理時間的元素。例如，載入一張圖片比應用過濾器花費更少的時間。訊息佇列通過一個緩衝層來幫助任務最高效率的執行———寫入佇列的處理會盡可能的快速。該緩衝有助於控制和優化資料流經過系統的速度。

• 非同步通訊

  很多時候，使用者不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許使用者把一個訊息放入佇列，但並不立即處理它。想向佇列中放入多少訊息就放多少，然後在需要的時候再去處理它們。

常用Message Queue對比

• RabbitMQ

  RabbitMQ是使用Erlang編寫的一個開源的訊息佇列，本身支援很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合於企業級的開發。同時實現了Broker構架，這意味著訊息在傳送給客戶端時先在中心佇列排隊。對路由，負載均衡或者資料持久化都有很好的支援。

• Redis

  Redis是一個基於Key-Value對的NoSQL資料庫，開發維護很活躍。雖然它是一個Key-Value資料庫儲存系統，但它本身支援MQ功能，所以完全可以當做一個輕量級的佇列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試資料分為128Bytes、512Bytes、1K和10K四個不同大小的資料。實驗表明：入隊時，當資料比較小時Redis的效能要高於RabbitMQ，而如果資料大小超過了10K，Redis則慢的無法忍受；出隊時，無論資料大小，Redis都表現出非常好的效能，而RabbitMQ的出隊效能則遠低於Redis。

• ZeroMQ

  ZeroMQ號稱最快的訊息佇列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高階/複雜的佇列，但是開發人員需要自己組合多種技術框架，技術上的複雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中介軟體的模式，你不需要安裝和執行一個訊息伺服器或中介軟體，因為你的應用程式將扮演這個伺服器角色。你只需要簡單的引用ZeroMQ程式庫，可以使用NuGet安裝，然後你就可以愉快的在應用程式之間傳送訊息了。但是ZeroMQ僅提供非永續性的佇列，也就是說如果宕機，資料將會丟失。其中，Twitter的Storm 0.9.0以前的版本中預設使用ZeroMQ作為資料流的傳輸（Storm從0.9版本開始同時支援ZeroMQ和Netty作為傳輸模組）。

• ActiveMQ

  ActiveMQ是Apache下的一個子專案。 類似於ZeroMQ，它能夠以代理人和點對點的技術實現佇列。同時類似於RabbitMQ，它少量程式碼就可以高效地實現高階應用場景。

• Kafka/Jafka

  Kafka是Apache下的一個子專案，是一個高效能跨語言分散式釋出/訂閱訊息佇列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行訊息持久化；高吞吐，在一臺普通的伺服器上既可以達到10W/s的吞吐速率；完全的分散式系統，Broker、Producer、Consumer都原生自動支援分散式，自動實現負載均衡；支援Hadoop資料並行載入，對於像Hadoop的一樣的日誌資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行載入機制統一了線上和離線的訊息處理。Apache Kafka相對於ActiveMQ是一個非常輕量級的訊息系統，除了效能非常好之外，還是一個工作良好的分散式系統。

在大資料系統中，常常會碰到一個問題，整個大資料是由各個子系統組成，資料需要在各個子系統中高效能，低延遲的不停流轉。傳統的企業訊息系統並不是非常適合大規模的資料處理。為了已在同時搞定線上應用（訊息）和離線應用（資料檔案，日誌）Kafka就出現了。Kafka可以起到兩個作用：

1. 降低系統組網複雜度。
2. 降低程式設計複雜度，各個子系統不在是相互協商介面，各個子系統類似插口插在插座上，Kafka承擔高速資料匯流排的作用。

Kafka主要特點：

1. 同時為釋出和訂閱提供高吞吐量。據瞭解，Kafka每秒可以生產約25萬訊息（50 MB），每秒處理55萬訊息（110 MB）。
2. 可進行持久化操作。將訊息持久化到磁碟，因此可用於批量消費，例如ETL，以及實時應用程式。通過將資料持久化到硬碟以及replication防止資料丟失。
3. 分散式系統，易於向外擴充套件。所有的producer、broker和consumer都會有多個，均為分散式的。無需停機即可擴充套件機器。
4. 訊息被處理的狀態是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。
5. 支援online和offline的場景。

Kafka的架構：

Kafka的整體架構非常簡單，是顯式分散式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer實現Kafka註冊的介面，資料從producer傳送到broker，broker承擔一箇中間快取和分發的作用。broker分發註冊到系統中的consumer。broker的作用類似於快取，即活躍的資料和離線處理系統之間的快取。客戶端和伺服器端的通訊，是基於簡單，高效能，且與程式語言無關的TCP協議。幾個基本概念：

1. Topic：特指Kafka處理的訊息源（feeds of messages）的不同分類。
2. Partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的佇列。partition中的每條訊息都會被分配一個有序的id（offset）。
3. Message：訊息，是通訊的基本單位，每個producer可以向一個topic（主題）釋出一些訊息。
4. Producers：訊息和資料生產者，向Kafka的一個topic釋出訊息的過程叫做producers。
5. Consumers：訊息和資料消費者，訂閱topics並處理其釋出的訊息的過程叫做consumers。
6. Broker：快取代理，Kafa叢集中的一臺或多臺伺服器統稱為broker。

訊息傳送的流程：

1. Producer根據指定的partition方法（round-robin、hash等），將訊息釋出到指定topic的partition裡面
2. kafka叢集接收到Producer發過來的訊息後，將其持久化到硬碟，並保留訊息指定時長（可配置），而不關注訊息是否被消費。
3. Consumer從kafka叢集pull資料，並控制獲取訊息的offset

Kafka的設計：

1、吞吐量

高吞吐是kafka需要實現的核心目標之一，為此kafka做了以下一些設計：

1. 資料磁碟持久化：訊息不在記憶體中cache，直接寫入到磁碟，充分利用磁碟的順序讀寫效能
2. zero-copy：減少IO操作步驟
3. 資料批量傳送
4. 資料壓縮
5. Topic劃分為多個partition，提高parallelism  並行。
   

2、負載均衡

1. producer根據使用者指定的演算法，將訊息傳送到指定的partition
2. 存在多個partiiton，每個partition有自己的replica，每個replica分佈在不同的Broker節點上
3. 多個partition需要選取出lead partition，lead partition負責讀寫，並由zookeeper負責fail over
4. 通過zookeeper管理broker與consumer的動態加入與離開

3、拉取系統

由於kafka broker會持久化資料，broker沒有記憶體壓力，因此，consumer非常適合採取pull的方式消費資料，具有以下幾點好處：

1. 簡化kafka設計
2. consumer根據消費能力自主控制訊息拉取速度
3. consumer根據自身情況自主選擇消費模式，例如批量，重複消費，從尾端開始消費等

4、可擴充套件性

當需要增加broker結點時，新增的broker會向zookeeper註冊，而producer及consumer會根據註冊在zookeeper上的watcher感知這些變化，並及時作出調整。

Kayka的應用場景：

1.訊息佇列

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

2.行為跟蹤

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

3.元資訊監控

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

4.日誌收集

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

5.流處理

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

6.事件源

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

7.永續性日誌（commit log）

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

Kayka的設計要點：

1、直接使用linux 檔案系統的cache，來高效快取資料。

2、採用linux Zero-Copy提高發送效能。傳統的資料傳送需要傳送4次上下文切換，採用sendfile系統呼叫之後，資料直接在核心態交換，系統上下文切換減少為2次。根據測試結果，可以提高60%的資料傳送效能。Zero-Copy詳細的技術細節可以參考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

3、資料在磁碟上存取代價為O(1)。kafka以topic來進行訊息管理，每個topic包含多個part（ition），每個part對應一個邏輯log，有多個segment組成。每個segment中儲存多條訊息（見下圖），訊息id由其邏輯位置決定，即從訊息id可直接定位到訊息的儲存位置，避免id到位置的額外對映。每個part在記憶體中對應一個index，記錄每個segment中的第一條訊息偏移。釋出者發到某個topic的訊息會被均勻的分佈到多個part上（隨機或根據使用者指定的回撥函式進行分佈），broker收到釋出訊息往對應part的最後一個segment上新增該訊息，當某個segment上的訊息條數達到配置值或訊息釋出時間超過閾值時，segment上的訊息會被flush到磁碟，只有flush到磁碟上的訊息訂閱者才能訂閱到，segment達到一定的大小後將不會再往該segment寫資料，broker會建立新的segment。

4、顯式分散式，即所有的producer、broker和consumer都會有多個，均為分散式的。Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行註冊，且zookeeper會儲存他們的一些元資料資訊。如果某個broker和consumer發生了變化，所有其他的broker和consumer都會得到通知。