流平臺的三要素：
1、提供釋出/訂閱記錄流的能力，類似於訊息佇列；
2、對記錄流的儲存有容錯能力；
3、可以即時處理記錄流。
kafka可用於兩大類應用：
1、建立實時流資料管道，在系統或應用之間進行可靠傳輸；
2、建立基於實時流的應用，可以傳輸或處理資料流。
先知概念：
*kafka執行在單個或多伺服器的叢集中；
*kafka叢集儲存的記錄（records）流被稱為主題（topices）；
*每一條記錄持有一個主鍵（key），一個值（value），一個時戳（timestamp）。
kafka有四個核心API族：
*Porducer API(生產者API)允許應用釋出一個流記錄到一個或多個kafka主題（topics）
*消費者API（Consumer API)允許應用訂閱一個或多個主題並處理主題生產的記錄流
*流API（Streams API）允許一個應用扮演一個流處理器，消費從一個或多個主題得到的資料流，併產生一個輸出流到若干個輸出主題，也就是把輸入流轉變為輸出流。
*聯結器API（Connector API）允許構建並執行可重複使用的生產者或消費者，他們可以把kafka的主題連線到已存在的應用或資料系統。比如，一個關係資料庫的聯結器（扮演消費者或生產者）可以捕獲一個數據表的每一個修改（扮演主題）。
一個主題代表了已釋出的記錄組。主題支援多人訂閱，一個主題可以有0個或多個消費訂閱它的寫入資料。
kafka叢集為每一個主題保留了一個分割槽記錄。每個分割槽都是有序的、包含序列記錄集，並不斷追加帶格式的提交日誌。分割槽中的記錄集中，每一條記錄都有一個有序唯一的ID號，稱之為“偏移量（offset）”。
kafka叢集保留了所有已釋出的記錄集，而不論他們是否被消費掉，保留週期可以配置。比如，如果保留規則是兩天，那麼當一條可消費記錄釋出兩天後，它將會被刪除來釋放空間。kafka可以有效的保持資料的固定大小，因而長時間儲存資料也不是問題。
事實上，日誌中基於單個消費者的元資料只有偏移量和消費者的讀寫位置。而偏移量也是受消費者控制：通常，一個消費者可能優先線性讀取記錄集，其實因為讀寫位置也是受消費者控制的，因而它可以按任意順序消費記錄集。比如一個消費者可以重置偏移量到一箇舊的位置然後處理資料，或者向前跳過大部分最近的記錄然後消費“現在”這個記錄。
從上面的功能我們可以看出，kafka的消費者佔用的資源是非常少的，他們可以隨時訂閱處理記錄而不會影響叢集或者其他人。你可以用命令列工具“tail“到某個主題而不改變其他消費者的消費動作。
日誌分割槽可以達成幾個目的。首先，存放在單伺服器中長度固定的日誌檔案可以被擴充套件。每個分割槽個體都要被儲存到託管伺服器中，而一個主題可能存在於多個分割槽中，所以它可以處理任意多的資料。其次，他們更多的是扮演了並行單元的角色。
分散式
日誌的分割槽是分佈在kafka叢集的伺服器上面的，每個伺服器共享處理分割槽的資料和請求。每個分割槽可以備份在可配置數量的伺服器中用於容錯機制。
每個分割槽的備份伺服器中，有一個扮演leader的角色，其他伺服器作為followers。leader處理分割槽所有的讀寫請求，而follower備份leader。如果leader執行出錯，其中一個follower會自動成為新的leader。一個伺服器對某些分割槽來說是leader，但對其他分割槽來說是follower，因而叢集具有很好的負載平衡。
生產者
生產者把資料釋出到他們選擇的主題中。生產者負責指定主題中的哪條記錄關聯到哪個分割槽。該操作可以在一個迴圈中完成以達到簡單的負載均衡，或者依照某個分割槽函式完成（比如基於記錄的主鍵）。大部分分割槽都用第二種方法。
消費者
消費者用消費者組名稱來標註他們自己。每一條釋出到一個主題的記錄都會交付給每個訂閱消費者組中的一個消費者例項。消費者例項可以執行在多執行緒或者多主機中。
如果所有的消費者例項在同一個消費者組中，則所有的記錄組會按照消費者例項進行有效的負載均衡。
如果所有的消費者例項在不同的消費者組中，則每一條記錄會被廣播到所有的消費者程序中。
上圖中，一個擁有兩臺伺服器的kafka叢集託管了四個分割槽（P0-P3），並有兩個消費者組。消費者組A有兩個消費者，消費者組B有四個。
普遍情況下，我們發現主題擁有小量的消費者組，一對多個“邏輯訂閱者”。每個組由多個消費者例項組成，便於擴充套件和容錯。而這無非是“釋出者-訂閱者”結構，只是訂閱者是消費者叢集而不是單一程序。
kafka實現的消費行為是通過按照消費者例項分割日誌中的分割槽，所以任意時刻，每個例項都是一個“公平共享”分割槽的獨有消費者。消費者組中維持這種成員關係的過程被依照kafka的協議動態處理。如果新的例項們加入到消費者組，他們會接管組中其他成員的部分分割槽。如果一個例項死亡，他的分割槽會被再分配給剩餘的例項。
kafka只提供一個主題在一個分割槽（而不是不同分割槽）中基於記錄的全序關係。大部分應用中，每個分割槽內的排序只需和分割槽資料的“鍵值”關係相關就足夠了。然而，如果你要求從僅有的一個分割槽獲取一個主題的記錄的全序關係，那這意味著一個消費者組中只有一個消費者程序。（因為如前面說的，一個消費者組中，一個分割槽被一個消費者管理，一個消費者管理多個分割槽）
承諾
kafka提供以下承諾：
*一個生產者傳送給一個特定主題分割槽的訊息，會按傳送順序排列。也就是，如果訊息M1和訊息M2傳送自同一個生產者，而且M1先發，那麼在日誌中M1比M2出現的更早偏移量更小。
*一個消費者看到的記錄集和他們在日誌中儲存的順序一致。
*一個主題的備份因子是N，我們可以容忍0到N-1的伺服器都出錯而不丟失任何提交到日誌中的記錄。
把kafka用做訊息系統
如何把kafka的流概念比做傳統的訊息系統呢？
傳統訊息傳輸有兩種模式：訊息佇列和釋出者-訂閱者。在一個訊息佇列中，消費者池從一個伺服器讀取訊息而每條記錄會發往消費者之一。在釋出者-訂閱者中，記錄會廣播給所有的訂閱者。兩種模式都有其優點和短板。訊息佇列的優點是允許你把資料處理分割到多個消費者例項，這些例項可以擴充套件你的操作過程。不幸的是，佇列不能多訂閱者同時處理一個程序讀到的資料。釋出者-訂閱者允許你廣播資料到多個處理程序，但在每條訊息抵達每個訂閱者之前無法擴充套件處理程序。
kafka中消費者組的概念統一了這兩種模型。作為訊息佇列，消費者組允許你分割處理過程到一組程序（消費者組的成員）。作為釋出者-消費者，kafka允許你廣播訊息到多個消費者組。
kafka模型的優點是每個主題都有兩方面屬性————它可以擴充套件操作過程也支援多使用者訂閱————不需要二選一。
kafka也有比傳統訊息系統更嚴格的序列性。
維持一個傳統訊息佇列服務中記錄保持有序，如果多個消費者要消費佇列的訊息，那麼伺服器會按照記錄儲存的順序取出他們。然而，雖然服務取出訊息是有序的，但是記錄分配給消費者是非同步的，所以他們到達不同消費者時可能已經亂序。也就是說記錄的順序會在並行執行時丟失。訊息系統經常用變通的方法稱之為“特殊消費者”，只允許一個程序消費一個佇列，但是這就不是並行處理了。
kafka做的更好。通過一個主題中的並行概念————分割槽，kafka可以保證基於消費者程序池的有序性和負載均衡。這個保證，是通過關聯主題的分割槽和消費者組中的消費者獲得，即每一個分割槽只能被組中確定的一個消費者所消費。通過這麼做，我們可以確定這個消費者就是這個分割槽唯一的讀取者，消費資料也是有序的。即使有多個分割槽被多個消費者例項所消費也可以保持負載均衡。（上文的：只有主分割槽可以被讀寫，每個分割槽都是某個主分割槽同時是別的記錄的從分割槽）。但是要注意，消費者組裡的消費者例項不能多於分割槽例項。
kafka做為儲存系統
有些訊息佇列把傳送訊息和處理訊息解耦，就好像一個動態訊息的儲存系統。這是不同於kafka的一個很好的儲存系統。
kafka把資料寫入磁碟並冗餘備份。kafka要求生產者等待從資料寫入失敗到備份完成等過程的確認訊息，並把訊息持久化（即使過程中伺服器寫入失敗）。
kafka使用的磁碟結構具有很好的擴充套件性————kafka對50K或50T的資料都會執行同樣的持久化到伺服器。
通過認真對待儲存的結果和允許客戶端控制他們的讀取位置，你可以想象kafka是一種用於特殊目的的分散式檔案系統，擁有高效能，低延遲的對提交日誌的儲存，備份和傳播。
kafka用做流資料處理
資料流不僅僅是讀、寫、儲存，更重要的是實時處理資料流。
kafka系統中，一個流處理過程從輸入主題獲取持續的資料流，在這個輸入上做一些操作處理，然後生成持續的輸出流到輸出主題。
舉例來說，一個零售商應用持續輸入銷售和發貨的資料流，持續輸出訂單流並根據訂單進行價格調整。
直接用生產者-消費者API可能也可以簡單直接的處理這個過程。而面對更復雜的變化，kafka提供了功能完備的Streams API。從此構建應用時，不需要再考慮處理過程中計算流的聚合或者把流拼一起等瑣碎的細節。
事實上，這解決了該型別應用面對的最困難問題：處理無序資料，程式碼修改後重新處理輸入資料，進行有狀態計算，等等。
流API構建了kafka核心基本單元，提供了：把生產者和消費者API用做輸入，使用kafka做有狀態儲存，用相同的組機制實現流處理例項的容錯。