是什麼？

一個分散式的訊息系統（訊息佇列），在流式計算中，一般用來快取資料。kafka作為一個叢集執行中在一個或多個伺服器上。

主要核心元件

• Topic：訊息根據Topic進行歸類
• Producer：訊息生產者，就是向kafka broker發訊息的客戶端。
• Consumer：訊息消費者，向kafka broker取訊息的客戶端。
• broker：每個kafka例項(server)，一臺kafka伺服器就是一個broker，一個叢集由多個broker組成，一個broker可以容納多個topic。
• Zookeeper：依賴叢集儲存meta資訊。

kafka叢集儲存的訊息以topic區分，每一個訊息由一個key，一個value和時間戳構成。

kafka有四個核心API：

• 使用 Producer API 釋出訊息到1個或多個topic（主題）。
• 使用 Consumer API 來訂閱一個或多個topic，並處理產生的訊息。
• 使用 Streams API 充當一個流處理器，從1個或多個topic消費輸入流，並生產一個輸出流到1個或多個輸出topic，有效地將輸入流轉換到輸出流。
• Connector API允許構建或執行可重複使用的生產者或消費者，將topic連線到現有的應用程式或資料系統。例如，一個關係資料庫的聯結器可捕獲每一個變化。

主要功能

作為一個分散式流平臺

一個流處理平臺具有三個關鍵能力：

• 釋出和訂閱訊息（流），在這方面，它類似於一個訊息佇列或企業訊息系統。
• 以容錯的方式儲存訊息（流）。
• 在訊息流發生時處理它們。

作用：

• 構建實時的流資料管道，可靠地獲取系統和應用程式之間的資料。
• 構建實時流的應用程式，對資料流進行轉換或反應。

作為一個訊息系統

Kafka的流與傳統企業訊息系統相比的概念如何？

傳統的訊息有兩種模式：佇列和釋出訂閱。

• 佇列模式：消費者池從伺服器讀取訊息（每個訊息只被其中一個讀取）;
• 釋出訂閱模式：訊息廣播給所有的消費者。接收到訊息的消費者都可以處理此訊息。

佇列

優點：允許多個消費者瓜分處理資料，可以擴充套件處理。 缺點：佇列不像多個訂閱者，一旦訊息者程序讀取後故障了，那麼訊息就丟了。

釋出和訂閱

優點：允許廣播資料到多個消費者 缺點：由於每個訂閱者都訂閱了訊息，所以沒辦法縮放處理。

Kafka為這兩種模型提供了單一的消費者抽象模型： 消費者組 （consumer group）。

kafka中消費者組有兩個概念：

佇列：消費者組允許同名的消費者組成員瓜分處理。 釋出訂閱：允許你廣播訊息給多個消費者組（不同名）

優勢：

kafka的每個topic都具有這兩種模式。 kafka有比傳統的訊息系統更強的順序保證。

怎麼使用單一的消費者模型抽象出佇列和釋出訂閱模型？

消費者用一個消費者組名標記自己。 一個釋出在Topic上訊息被分發給此消費者組中的一個消費者。

• 假如所有的消費者都在一個組中，那麼這就變成了queue模型。
• 假如所有的消費者都在不同的組中，那麼就完全變成了釋出-訂閱模型。
• 更通用的， 我們可以建立一些消費者組作為邏輯上的訂閱者。每個組包含數目不等的消費者， 一個組內多個消費者可以用來擴充套件效能和容錯。

傳統的訊息系統缺陷

傳統的訊息系統按順序儲存資料，如果多個消費者佇列消費，則伺服器按儲存的順序傳送訊息，但是，儘管伺服器按順序傳送，訊息非同步傳遞到消費者，因此訊息可能亂序到達消費者。這意味著訊息存在並行消費的情況，順序就無法保證。訊息系統常常通過僅設1個消費者來解決這個問題，但是這意味著沒用到並行處理。

kafka的優勢

通過並行topic的partition ，kafka提供了順序保證和負載均衡。 每個partition僅由同一個消費者組中的一個消費者消費到。並確保消費者是該partition的唯一消費者，並按順序消費資料。每個topic有多個分割槽，則需要對多個消費者做負載均衡，但請注意，相同的消費者組中不能有比分割槽更多的消費者，否則多出的消費者一直處於空等待，不會收到訊息。

作為一個儲存系統

所有釋出訊息到訊息佇列和消費分離的系統，實際上都充當了一個儲存系統（釋出的訊息先儲存起來）。 Kafka比別的系統的優勢是它是一個非常高效能的儲存系統。

優點：

• 寫入到kafka的資料將寫到磁碟並複製到叢集中保證容錯性。
• 允許生產者等待訊息應答，直到訊息完全寫入。
• kafka的磁碟結構，無論你伺服器上有50KB或50TB，執行是相同的。
• client來控制讀取資料的位置。 也可以認為kafka是一種專用於高效能，低延遲，提交日誌儲存，複製，和傳播特殊用途的分散式檔案系統。

流處理

僅僅讀，寫和儲存是不夠的，kafka的目標是實時的流處理。 在kafka中，流處理持續獲取輸入topic的資料，進行處理加工，然後寫入輸出topic。 例如，一個零售APP，接收銷售和出貨的輸入流，統計數量或調整價格後輸出。 可以直接使用producer和consumer API進行簡單的處理。對於複雜的轉換，Kafka提供了更強大的Streams API。可構建聚合計算或連線流到一起的複雜應用程式，解決此類應用面臨的硬性問題：處理無序的資料，程式碼更改的再處理，執行狀態計算等。

Sterams API在Kafka中的核心：

使用producer和consumer API作為輸入，利用Kafka做狀態儲存，使用相同的組機制在stream處理器例項之間進行容錯保障。

功能總結

訊息傳遞，儲存和流處理的組合看似反常，但對於Kafka作為流式處理平臺的作用至關重要。

比較一下HDFS（分散式檔案系統）

像HDFS這樣的分散式檔案系統允許儲存靜態檔案來進行批處理。 這樣系統可以有效地儲存和處理來自過去的歷史資料。

傳統企業的訊息系統

允許在你訂閱之後處理未來的訊息：在未來資料到達時處理它。

kafka

kafka結合了這兩種能力，這種組合對於kafka作為流處理應用和流資料管道平臺是至關重要的。

批處理以及訊息驅動應用程式的流處理的概念：

通過組合儲存和低延遲訂閱，流處理應用可以用相同的方式對待過去和未來的資料。它是一個單一的應用程式，它可以處理歷史的儲存資料，當它處理到最後一個訊息時，它進入等待未來的資料到達，而不是結束。

對於流資料管道（pipeline）

訂閱實時事件的組合使得可以將Kafka用於非常低延遲的管道；但是，可靠地儲存資料的能力使得它可以將其用於必須保證傳遞的關鍵資料，或與僅定期載入資料或長時間維護的離線系統整合在一起。流處理可以在資料到達時轉換它。

關於Apache kafka 流行的使用場景

訊息

kafka更好的替換傳統的訊息系統，訊息系統被用於各種場景（解耦資料生產者，快取未處理的訊息等），與大多數訊息系統比較，kafka有更好的吞吐量，內建分割槽，副本和故障轉移，這有利於處理大規模的訊息。根據我們的經驗，訊息往往用於較低的吞吐量，但需要低的端到端延遲，並需要提供強大的耐用性的保證。在這一領域的kafka比得上傳統的訊息系統，如的ActiveMQ或RabbitMQ的。

網站活動追蹤

kafka原本的使用場景：使用者的活動追蹤，網站的活動（網頁遊覽，搜尋或其他使用者的操作資訊）釋出到不同的話題中心，這些訊息可實時處理，實時監測，也可載入到Hadoop或離線處理資料倉庫。每個使用者頁面檢視都會產生非常高的量。

指標

kafka也常常用於監測資料。分散式應用程式生成的統計資料集中聚合。

日誌聚合

使用kafka代替一個日誌聚合的解決方案。

流處理

kafka訊息處理包含多個階段。其中原始輸入資料是從kafka主題消費的，然後彙總，豐富，或者以其他的方式處理轉化為新主題，例如，一個推薦新聞文章，文章內容可能從“articles”主題獲取；然後進一步處理內容，得到一個處理後的新內容，最後推薦給使用者。這種處理是基於單個主題的實時資料流。從0.10.0.0開始，輕量，但功能強大的流處理，就進行這樣的資料處理了。除了Kafka Streams，還有Apache Storm和Apache Samza可選擇。

事件採集

事件採集是一種應用程式的設計風格，其中狀態的變化根據時間的順序記錄下來，kafka支援這種非常大的儲存日誌資料的場景。

提交日誌

kafka可以作為一種分散式的外部提交日誌，日誌幫助節點之間複製資料，並作為失敗的節點來恢復資料重新同步，kafka的日誌壓縮功能很好的支援這種用法，這種用法類似於Apacha BookKeeper專案。