kafka入門介紹（轉載）

Kafka作為一個分布式的流平臺，這到底意味著什么？

我們認為，一個流處理平臺具有三個關鍵能力：

發布和訂閱消息（流），在這方面，它類似于一個消息隊列或企業消息系統。

以容錯的方式存儲消息（流）。

在消息流發生時處理它們。

什么是kakfa的優勢？

它應用于2大類應用：

構建實時的流數據管道，可靠地獲取系統和應用程序之間的數據。

構建實時流的應用程序，對數據流進行轉換或反應。

要了解kafka是如何做這些事情的，讓我們從下到上深入探討kafka的能力。

首先幾個概念：

kafka作為一個集群運行在一個或多個服務器上。

kafka集群存儲的消息是以topic為類別記錄的。

每個消息（也叫記錄record，我習慣叫消息）是由一個key，一個value和時間戳構成。

kafka有四個核心API：

應用程序使用Producer API發布消息到1個或多個topic（主題）。

應用程序使用Consumer API來訂閱一個或多個topic，并處理產生的消息。

應用程序使用Streams API充當一個流處理器，從1個或多個topic消費輸入流，并生產一個輸出流到1個或多個輸出topic，有效地將輸入流轉換到輸出流。

Connector API允許構建或運行可重復使用的生產者或消費者，將topic連接到現有的應用程序或數據系統。例如，一個關系數據庫的連接器可捕獲每一個變化。

Client和Server之間的通訊，是通過一條簡單、高性能并且和開發語言無關的TCP協議。除了Java Client外，還有非常多的其它編程語言的Client。

首先來了解一下Kafka所使用的基本術語：

Topic

Kafka將消息種子(Feed)分門別類，每一類的消息稱之為一個主題(Topic).

Producer

發布消息的對象稱之為主題生產者(Kafka topic producer)

Consumer

訂閱消息并處理發布的消息的種子的對象稱之為主題消費者(consumers)

Broker

已發布的消息保存在一組服務器中，稱之為Kafka集群。集群中的每一個服務器都是一個代理(Broker). 消費者可以訂閱一個或多個主題（topic），并從Broker拉數據，從而消費這些已發布的消息。

話題和日志? (Topic和Log)

讓我們更深入的了解Kafka中的Topic。

Topic是發布的消息的類別或者種子Feed名。對于每一個Topic，Kafka集群維護這一個分區的log，就像下圖中的示例：

每一個分區都是一個順序的、不可變的消息隊列，并且可以持續的添加。分區中的消息都被分了一個序列號，稱之為偏移量(offset)，在每個分區中此偏移量都是唯一的。

Kafka集群保持所有的消息，直到它們過期，無論消息是否被消費了。實際上消費者所持有的僅有的元數據就是這個偏移量，也就是消費者在這個log中的位置。這個偏移量由消費者控制：正常情況當消費者消費消息的時候，偏移量也線性的的增加。但是實際偏移量由消費者控制，消費者可以將偏移量重置為更老的一個偏移量，重新讀取消息。可以看到這種設計對消費者來說操作自如，一個消費者的操作不會影響其它消費者對此log的處理。再說說分區。Kafka中采用分區的設計有幾個目的。一是可以處理更多的消息，不受單臺服務器的限制。Topic擁有多個分區意味著它可以不受限的處理更多的數據。第二，分區可以作為并行處理的單元，稍后會談到這一點。

分布式(Distribution)

Log的分區被分布到集群中的多個服務器上。每個服務器處理它分到的分區。根據配置每個分區還可以復制到其它服務器作為備份容錯。每個分區有一個leader，零或多個follower。Leader處理此分區的所有的讀寫請求，而follower被動的復制數據。如果leader宕機，其它的一個follower會被推舉為新的leader。一臺服務器可能同時是一個分區的leader，另一個分區的follower。這樣可以平衡負載，避免所有的請求都只讓一臺或者某幾臺服務器處理。

生產者(Producers)

生產者往某個Topic上發布消息。生產者也負責選擇發布到Topic上的哪一個分區。最簡單的方式從分區列表中輪流選擇。也可以根據某種算法依照權重選擇分區。開發者負責如何選擇分區的算法。

消費者(Consumers)

通常來講，消息模型可以分為兩種，隊列和發布-訂閱式。隊列的處理方式是一組消費者從服務器讀取消息，一條消息只有其中的一個消費者來處理。在發布-訂閱模型中，消息被廣播給所有的消費者，接收到消息的消費者都可以處理此消息。Kafka為這兩種模型提供了單一的消費者抽象模型：消費者組（consumer group）。消費者用一個消費者組名標記自己。一個發布在Topic上消息被分發給此消費者組中的一個消費者。假如所有的消費者都在一個組中，那么這就變成了queue模型。假如所有的消費者都在不同的組中，那么就完全變成了發布-訂閱模型。更通用的，我們可以創建一些消費者組作為邏輯上的訂閱者。每個組包含數目不等的消費者，一個組內多個消費者可以用來擴展性能和容錯。正如下圖所示：

2個kafka集群托管4個分區（P0-P3），2個消費者組，消費組A有2個消費者實例，消費組B有4個。

正像傳統的消息系統一樣，Kafka保證消息的順序不變。再詳細扯幾句。傳統的隊列模型保持消息，并且保證它們的先后順序不變。但是，盡管服務器保證了消息的順序，消息還是異步的發送給各個消費者，消費者收到消息的先后順序不能保證了。這也意味著并行消費將不能保證消息的先后順序。用過傳統的消息系統的同學肯定清楚，消息的順序處理很讓人頭痛。如果只讓一個消費者處理消息，又違背了并行處理的初衷。在這一點上Kafka做的更好，盡管并沒有完全解決上述問題。 Kafka采用了一種分而治之的策略：分區。因為Topic分區中消息只能由消費者組中的唯一一個消費者處理，所以消息肯定是按照先后順序進行處理的。但是它也僅僅是保證Topic的一個分區順序處理，不能保證跨分區的消息先后處理順序。所以，如果你想要順序的處理Topic的所有消息，那就只提供一個分區。

Kafka的保證(Guarantees)

生產者發送到一個特定的Topic的分區上，消息將會按照它們發送的順序依次加入，也就是說，如果一個消息M1和M2使用相同的producer發送，M1先發送，那么M1將比M2的offset低，并且優先的出現在日志中。

消費者收到的消息也是此順序。

如果一個Topic配置了復制因子（replication facto）為N，那么可以允許N-1服務器宕機而不丟失任何已經提交（committed）的消息。

有關這些保證的更多詳細信息，請參見文檔的設計部分。

kafka作為一個消息系統

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

傳統的消息有兩種模式：隊列和發布訂閱。在隊列模式中，消費者池從服務器讀取消息（每個消息只被其中一個讀取）; 發布訂閱模式：消息廣播給所有的消費者。這兩種模式都有優缺點，隊列的優點是允許多個消費者瓜分處理數據，這樣可以擴展處理。但是，隊列不像多個訂閱者，一旦消息者進程讀取后故障了，那么消息就丟了。而發布和訂閱允許你廣播數據到多個消費者，由于每個訂閱者都訂閱了消息，所以沒辦法縮放處理。

kafka中消費者組有兩個概念：隊列：消費者組（consumer group）允許同名的消費者組成員瓜分處理。發布訂閱：允許你廣播消息給多個消費者組（不同名）。

kafka的每個topic都具有這兩種模式。

kafka有比傳統的消息系統更強的順序保證。

傳統的消息系統按順序保存數據，如果多個消費者從隊列消費，則服務器按存儲的順序發送消息，但是，盡管服務器按順序發送，消息異步傳遞到消費者，因此消息可能亂序到達消費者。這意味著消息存在并行消費的情況，順序就無法保證。消息系統常常通過僅設1個消費者來解決這個問題，但是這意味著沒用到并行處理。

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

kafka作為一個存儲系統

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

寫入到kafka的數據將寫到磁盤并復制到集群中保證容錯性。并允許生產者等待消息應答，直到消息完全寫入。

kafka的磁盤結構 - 無論你服務器上有50KB或50TB，執行是相同的。

client來控制讀取數據的位置。你還可以認為kafka是一種專用于高性能，低延遲，提交日志存儲，復制，和傳播特殊用途的分布式文件系統。

kafka的流處理

僅僅讀，寫和存儲是不夠的，kafka的目標是實時的流處理。

在kafka中，流處理持續獲取輸入topic的數據，進行處理加工，然后寫入輸出topic。例如，一個零售APP，接收銷售和出貨的輸入流，統計數量或調整價格后輸出。

可以直接使用producer和consumer API進行簡單的處理。對于復雜的轉換，Kafka提供了更強大的Streams API。可構建聚合計算或連接流到一起的復雜應用程序。

助于解決此類應用面臨的硬性問題：處理無序的數據，代碼更改的再處理，執行狀態計算等。

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

拼在一起