轉載源：https://www.cnblogs.com/lsx1993/p/4627465.html

這個應該算是之前比較火熱的詞了，一直沒時間抽出來看看。一個新東西出來，肯定是為了解決某些問題，不然不會有它的市場。先簡單看下。

官方介紹：分散式、分割槽、支援複製的日誌提交系統
適用場景：顧名思義，特別適合用於系統日誌的非同步記錄，對於資料穩定性、一致性、可靠性要求不高的場景，追求的是高吞吐量。非傳統的MQ產品！

核心模型抽象：
　　topics：某種訊息的高層抽象
　　producers：訊息的生產者
　　consumers：訊息的消費者
　　broker：叢集中的每一個節點伺服器，多個broker組成一個叢集

整體結構圖

topic：
1.kafka叢集會將每個topic進行分割槽，每個分割槽都是一個排序且不可改變的佇列，新的訊息會進入隊尾並分配一個唯一ID，官方稱之為偏移量(offset)
2.無論訊息是否被消費，叢集都會保留訊息,有一個配置的時間（過期時間）,超過這個時間後，訊息會被清除
3.消費端唯一記錄的元資訊就是自己在topic中的位置(offset)，
4.分散式的原因：第一叢集可以容納大量的資料 第二：可以並行的處理

分散式
　　1.每一份資料都會複製到不同的伺服器上，以便與容錯處理
　　2.每一個topic的分割槽都會有一個leader,並有零個或是多個follower，所有的讀寫請求都會經過leader來進行分發

生產者
　　Producers會將資料傳送訊息到topic，傳送的目的地可以根據輪訓策略或是到指定的分割槽策略

消費者
　　訊息一般有兩種模式，其一是佇列，另一種是釋出訂閱。
　　佇列：有很多消費者，每一個消費者從佇列中獲取其中一個數據，一個數據只被消費一次。
　　釋出訂閱模式：將一個消費廣播到所有的消費者，一個數據會被消費N次。

kafka對於消費者提供了一種簡單的抽象 — 消費組。每一個消費者都會有一個消費組的名稱，一個消費會發布到一個topic上，同時遞送到訂閱了這個訊息的消費組下的所有消費者。具體如下圖所示：

若是所有的消費者都是相同的消費組，那麼就是一個佇列模式。

若是消費者有不同的組，那麼就是釋出訂閱模式，那麼消費就會遞送到所有的消費者。

通過對於消費組的名稱不同來區分了佇列和釋出訂閱模式。

每一個topic都會有一定數量的消費組，每個消費組(邏輯訂閱者)包含了多個消費者，這樣就可以保證可伸縮性金額容錯。這樣訂閱者就是一個叢集而不是單個例項。保證單點故障問題。
在強一致性上kafka同傳統的MQ也在靠近。
傳統的佇列是將訊息按照儲存時候的順序進行傳送，但是有多個消費者的時候，有可能發生到底每個消費者的順序不一定，一是導致無法並行，二是導致消費的順序不一致。為了解決這個問題，通常的手段是隻有一個消費者來保證順序。

針對上面兩個問題，kafka有自己的解決方案。解決並行是將多個分割槽分別指定對應的消費者，這樣就保證了並行，同時保證了訊息消費的順序，限制是消費者的數量不能多於分割槽數目(通過配置指定).

但是這樣就只能保證一個分割槽中的訊息是保證順序，無法保證不同分割槽的訊息的順序一致性。在大多數應用場景下，這樣是能滿足要求的，若是你要求非常強烈的一致性話，就只能單消費者了。

一致性
1.topic接受到訊息並儲存到佇列中，若是收到M1，M2兩個訊息，那麼在佇列中M1的偏移量會小於M2
2.消費者看到訊息的順序就是在儲存到日誌上的順序
3.一個topic的複製因子是N，那麼訊息會被複制到N-1伺服器上，保證訊息的不丟失

一些常見的使用場景
1.作為訊息處理系統
作用:解耦訊息的生產和處理、快取訊息以緩解對於後端處理承受的壓力
可以比較的類似產品是ActiveMQ or RabbitMQ.

2.網頁行為記錄
一個使用者的行為記錄的消費者一般是多個，可能是實時處理系統，也可能是離線處理系統，同時吞吐量非常的大，kafka就非常的適合

3.監控 對於一些監控資料的處理

4.日誌聚合方案
這個是kafka最常用的地方，用於分散到多個地方的日誌做一個聚合，以便於後續的分析處理

5.流式處理
官方的說法是也可以把kafka當做類似Strom或Samza的流式處理框架來用，至於效果如何就未知

6.事件驅動架構
這種架構風格中的候選者之一
訊息框架的出現解決了很多問題，例如解耦訊息的生產和處理、快取訊息以緩解對於後端處理承受的壓力(提升效能.不同框架的設計決定了它的適用場景，kafka的topic分割槽並行設計決定了它的高吞吐量，但是不保證順序一致性,對於feed類就不友好

其他：
1.支援批量釋出
2.基於TCP協議，傳輸層協議，不需要任何的語義
3.有不同客戶端實現