還不會Kafka嗎？你真的成OUT慢了

1、定義

Apache Kafka 是一款開源的消息系統。能夠在系統中起到「肖峯填谷」的做用，也能夠用於異構、分佈式系統中海量數據的異步化處理。
系統包括四個主要API:

• Producer API
  容許一個應用推送流記錄經過一個或多個Kafka topics ；

• Consumer API
  容許一個應用訂閱一個或多個topics 而且處理這些流記錄；

• Streams API
  容許一個應用做爲一個流處理者，經過topics 輸入或輸出流數據 ；

• Connector API
  綁定並運行 Producer 或 Consumer 鏈接Kafka topics 到 到已經存在的系統或存儲上；

2、功能介紹

1) Topics and log

Topic 是發佈記錄的類別或訂閱源名稱。Kafka 的topic 會關聯用戶；一個topic 能夠有 0個或多個Consumer 訂閱寫入它的數據。
對於每一個topic ，kafka 集羣都會維護一個分區日誌，以下圖：

每一個分區都是一個有序的， 不可變的記錄序列， 不斷附加到結構化的提交日誌中。 分區中的記錄每一個都被分配一個稱爲偏移的順序ID號，它惟一標識分區中的每條記錄。
Kafka 集羣能夠持久的保存全部已發佈的記錄-不管它們是否被消費-能夠易配置保留期限。
每一個consumer 會保留消費者在日誌中消費的偏移或位置。一般消費者在讀取記錄的時候會線性提升偏移量，同時消費者也能夠按照本身喜歡的順序消費記錄。

Kafka 三層消息框架：
第一層：主題層，每一個主題能夠配置N個分區，每一個分區能夠配置M個副本。
第二層：分區層，每一個分區的M個副本， 只能有一個lender副本，其對外提供服務，其它M-1 個副本是 追隨者副本，只是提供數據冗餘之用（客戶端只會與分區中的leader副本進行交互）。
第三層：消息層，分區中包含若干條消息，每條消息的位移從0開始，依次遞增。

2）Distribution（消息分配）

日誌的分區分佈在Kafka 集羣中的服務器上，每臺服務器均可以處理請求數據。每一個分區都在可配置數量的服務器上進行復制，以實現容錯。
每一個分區只有一個服務器充當「leader」，0個或多個服務器充當「followers」，leader 節點處理分區全部的記錄讀取和寫入，followers節點 複製 leader 節點 的數據。 若是 leader 節點 異常，其中一個 followers 節點會被選舉爲 leader 節點。每一個服務器均可以充當某些分區的 leader 節點 和其它服務器的 followers 節點，所以負載均衡在集羣中獲得很好的平衡。

3）Geo-Replication（異地複製）

Kafka MirrorMaker爲您的羣集提供地理複製支持。使用MirrorMaker，能夠跨多個數據中心或雲區域複製數據。您能夠在主動/被動方案中使用它進行備份和恢復; 或者在主動/主動方案中，使數據更接近用戶，或支持數據位置要求。

4）Producers

生產者將數據發佈到他們選擇的主題。生產者負責選擇分配給主題中哪一個分區的記錄。這能夠經過循環方式完成，只是爲了平衡負載，或者能夠根據一些語義分區功能（例如基於記錄中的某些鍵）來完成。

5）Consumers

消費者使用消費者組名稱標記本身，而且發佈到主題的每一個記錄被傳遞到每一個訂閱消費者組中的一個消費者實例。消費者實例能夠在單獨的進程中，也能夠在不一樣的機器。
若是全部使用者實例具備相同的使用者組，則記錄將有效地在使用者實例上進行負載平衡。
若是全部消費者實例具備不一樣的消費者組，則每一個記錄將廣播到全部消費者進程。

兩個服務器Kafka羣集，託管四個分區（P0-P3），包含兩個使用者組。消費者組A有兩個消費者實例，B組有四個消費者實例。
在Kafka中實現消費的方式是經過在消費者實例上劃分日誌中的分區，以便每一個實例在任什麼時候間點都是分配的「公平份額」的獨佔消費者。維護組中成員資格的過程由Kafka協議動態處理。若是新實例加入該組，他們將從該組的其餘成員接管一些分區; 若是實例死亡，其分區將分發給其他實例。分區實現了Kafka 的高併發。

6）Guarantees（可靠性）

• 生產者發送到特定主題分區的消息將按其發送順序附加。也就是說，若是記錄M1由與記錄M2相同的生產者發送，而且首先發送M1，則M1將具備比M2更低的偏移而且在日誌中更早出現。

• 消費者實例按照它們存儲在日誌中的順序查看記錄。

• 對於具備複製因子N的主題，咱們將容忍最多N-1個服務器故障，而不會丟失任何提交到日誌的記錄。

3、實踐應用

1） Kafka 做爲消息系統

通用消息系統中有兩種消息模型：隊列 和 發佈-訂閱 。

• 隊列：隊列中的數據被一個消費節點讀取。它的優點在於容許在多個消費者實例上劃分數據處理。缺點是，隊列不支持多租戶，多個實例狀況下沒法讀取被其它實例消費的記錄。

• 發佈-訂閱：記錄被廣播給全部消費者，容許將數據廣播到多個消費者實例。

• 消息順序性：在通用隊列的模式裏，服務器上按順序保存記錄，若是有多個消費者從隊列中消費，則服務器按存儲順序分發記錄，但消息是異步傳遞給消費者的，
  所以他們可能會存在不一樣消費者上的無序傳送。

• 消息傳遞系統一般經過具備「獨佔消費者」的概念來解決這個問題，該概念只容許一個進程從隊列中消耗，但這固然意味着處理中沒有並行性。

kafka 經過在主題中具備並行性概念 - 分區 - ，Kafka可以在消費者流程池中提供訂購保證和負載平衡。這是經過將主題中的分區分配給使用者組中的使用者來實現的，以便每一個分區僅由該組中的一個使用者使用。經過這樣作，咱們確保使用者是該分區的惟一讀者並按順序使用數據。因爲有許多分區，這仍然能夠平衡許多消費者實例的負載。但請注意，消費者組中的消費者實例不能超過度區。

2）Kafka做爲存儲系統

任何容許發佈與消費它們分離的消息的消息隊列實際上充當了正在進行的消息的存儲系統。Kafka的不一樣之處在於它是一個很是好的存儲系統。

寫入Kafka的數據將寫入磁盤並進行復制以實現容錯。Kafka容許生產者等待確認，以便在徹底複製以前寫入不被認爲是完整的，而且即便寫入的服務器失敗也保證寫入仍然存在。

磁盤結構Kafka很好地使用了規模 - 不管服務器上有50 KB仍是50 TB的持久數據，Kafka都會執行相同的操做。

因爲認真對待存儲並容許客戶端控制其讀取位置，您能夠將Kafka視爲一種專用於高性能，低延遲提交日誌存儲，複製和傳播的專用分佈式文件系統。

3）Kafka用於流處理
僅僅讀取，寫入和存儲數據流是不夠的，目的是實現流的實時處理。

在Kafka中，流處理器是指從輸入主題獲取連續數據流，對此輸入執行某些處理以及生成連續數據流以輸出主題的任何內容。

例如，零售應用程序可能會接收銷售和發貨的輸入流，並輸出從新排序流和根據此數據計算的價格調整。

可使用生產者和消費者API直接進行簡單處理。可是，對於更復雜的轉換，Kafka提供了徹底集成的Streams API。這容許構建執行非平凡處理的應用程序，這些應用程序能夠計算流的聚合或將流鏈接在一塊兒。

此工具備助於解決此類應用程序面臨的難題：處理無序數據，在代碼更改時從新處理輸入，執行有狀態計算等。

流API構建在Kafka提供的核心原語上：它使用生產者和消費者API進行輸入，使用Kafka進行有狀態存儲，並在流處理器實例之間使用相同的組機制來實現容錯。

4、名詞解釋

• 消息：Record。Kafka是消息引擎，這裏的消息就是Kafka處理的主要對象。

• 主體：Topic。主題就是承載消息的邏輯容器，在實際應用中多用於區分具體業務。

• 消息位移：Offset。表示分區中每條消息的位置信息，是一個單調遞增不變的值。

• 副本：Replica。Kafka中一條消息可以被拷貝到多個地方以提供數據冗餘，這些地方就是所謂的副本。副本還分爲領導者副本和追隨者副本，各自有不一樣的角色劃分。副本是在分區層級下的，即每一個分區可配置多個副本實現高可用。

• 生產者：Producer 。 向主題發佈新消息的應用程序。

• 消費者：Consumer。從主題訂閱新消息的應用程序。

• 消費者位移：Consumer Offset 。表示消費者消費進度，每一個消費者都有本身的消費者位移。

• 消費者組：Consumer Group 。多個消費者實例共同組成的一個組，同時消費多個分區實現高吞吐。

• 重平衡：Rebalance。消費者組內某個消費者實例掛掉後，其它消費者實例自動從新分配訂閱主題分區的過程。Rebalance 是kafka消費者端實現高可用的重要手段。