簡介

?

Kafka擅長于做什么？

它被用于兩大類應用：

在應用間構建實時的數(shù)據(jù)流通道

構建傳輸或處理數(shù)據(jù)流的實時流式應用

幾個概念：

• Kafka以集群模式運行在1或多臺服務器上
• Kafka以topics的形式存儲數(shù)據(jù)流
• 每一個記錄包含一個key、一個value和一個timestamp

Kafka有4個核心API：

• Producer API：用于應用程序?qū)?shù)據(jù)流發(fā)送到一個或多個Kafka topics
• Consumer API：用于應用程序訂閱一個或多個topics并處理被發(fā)送到這些topics中的數(shù)據(jù)
• Streams API：允許應用程序作為流處理器，處理來自一個或多個topics的數(shù)據(jù)并將處理結果發(fā)送到一個或多個topics中，有效的將輸入流轉(zhuǎn)化為輸出流
• Connector API：用于構建和運行將Kafka topics和現(xiàn)有應用或數(shù)據(jù)系統(tǒng)連接的可重用的produers和consumers。例如，如鏈接到關系數(shù)據(jù)庫的連接器可能會捕獲某個表所有的變更

Kafka客戶端和服務端之間的通信是建立在簡單的、高效的、語言無關的TCP協(xié)議上的。此協(xié)議帶有版本且向后兼容。我們?yōu)镵afka提供了Java客戶端，但是客戶端可以使用多種語言。

Topics and Logs

Topic是發(fā)布記錄的類別。Kafka中的Topics一般是多訂閱者的，也就是一個Topic可以有0個或多個Consumer訂閱它的數(shù)據(jù)。

對于每個主題，Kafka會會維護一個如下所示的分區(qū)日志：

每個分區(qū)是一個有序的，以不可變的記錄順序追加的Commit Log。分區(qū)中的每個記錄都有一個連續(xù)的ID，稱為Offset，唯一標識分區(qū)內(nèi)的記錄。

Kafka集群使用記錄保存時間的配置來保存所有已發(fā)布的記錄（無論他們是否被消費）。例如，配置策略為兩天，那么在一條記錄發(fā)布兩天內(nèi)，這條記錄是可以被消費的，之后將被丟棄以騰出空間。Kafka的性能和數(shù)據(jù)量無關，所以存儲長時間的數(shù)據(jù)并不會成為問題。

實際上唯一需要保存的元數(shù)據(jù)是消費者的消費進度，即消費日志的偏移量（Offset）。這個Offset是由Consumer控制的：通常消費者會在讀取記錄時以線性方式提升Offset，但是事實上，由于Offset由Consumer控制，因此它可以以任何順序消費記錄。例如一個Consumer可以通過重置Offset來處理過去的數(shù)據(jù)或者跳過部分數(shù)據(jù)。

這個特征意味著Kafka的Consumer可以消費“過去”和“將來”的數(shù)據(jù)而不對集群和其他Consumer不造成太大的影響。例如，可以使用命令行工具tail來獲取Topic尾部的內(nèi)容而不對已經(jīng)在消費Consumer造成影響。

分區(qū)日志有幾個目的。第一，使服務器能承載日志的大小，每個分區(qū)的日志必須可以被保存在單個服務器上，但是一個Topic可以擁有多個分區(qū)，那么它可以處理任意大小的數(shù)據(jù)量。第二，它們作為并行度的單位（更多的是這點的考慮）。

Distribution

分區(qū)日志分布在集群中服務器中，每個服務器處理一部分分區(qū)的數(shù)據(jù)和請求。每個分區(qū)可以配置分布的服務器，以實現(xiàn)容錯。

每個分區(qū)擁有一個Leader節(jié)點，和零或多個Follower。Leader處理該分區(qū)所有的讀寫請求，Follower復制Leader數(shù)據(jù)。如果Leader節(jié)點宕機，將會有一個Follower節(jié)點自動的轉(zhuǎn)化為Leader。每個節(jié)點成為其部分分區(qū)的Leader，并成為剩余分區(qū)的Follower，這樣整個集群的負載將比較均衡。

Producers

Producer發(fā)送數(shù)據(jù)到它選擇的Topic。Producer負責決定將數(shù)據(jù)發(fā)送到Topic的那個分區(qū)上。這可以通過簡單的循環(huán)方式來平衡負載，或則可以根據(jù)某些語義來決定分區(qū)（例如基于數(shù)據(jù)中一些關鍵字）。

Consumers

Consumer使用一個group name來標識自己的身份，每條被發(fā)送到一個Topic的消息都將被分發(fā)到屬于同一個group的Consumer的一個實例中（group name相同的Consumer屬于一個組，一個Topic的一條消息會被這個組中的一個Consumer實例消費）。Consumer實例可以在單獨的進程中或者單獨的機器上。

如果所有的Consumer實例都是屬于一個group的，那么所有的消息將被均衡的分發(fā)給每個實例。

如果所有的Consumer都屬于不同的group，那么每條消息將被廣播給所有的Consumer。

（上圖）一個包含兩個Server的Kafka集群，擁有四個分區(qū)（P0-P3），有兩個Consumer group：Group A和Group B。Group有C1、C2兩個Consumer，GroupB有C3、C4、C5、C6四個Consumer。

更常見的是，Topic有少量的Consumer group，每一個都是“一個邏輯上的訂閱者”。每個group包含多個Consumer實例，為了可伸縮性和容錯性。這就是一個發(fā)布-訂閱模式，只是訂閱方是一個集群。

Kafka中消費的實現(xiàn)方式是“公平”的將分區(qū)分配給Consumer，每一個時刻分區(qū)都擁有它唯一的消費者。Consumer成員關系有Kafka程度動態(tài)維護。如果新的Consumer加入了分區(qū)，那么它會從這個分區(qū)其他的Consumer中分配走一部分分區(qū)；如果部分Consumer實例宕機，它的分區(qū)會被其他Consumer實例接管。

Kafka只保證同一個分區(qū)內(nèi)記錄的順序，而不是同一個Topic的不同分區(qū)間數(shù)據(jù)的順序。每個分區(qū)順序結合按Key分配分區(qū)的能力，能滿足大多數(shù)程序的需求。如果需要全局的順序，可以使用只有一個分區(qū)的Topic，這意味著每個group只能有一個Consumer實例（因為一個分區(qū)同一時刻只能被一份Consumer消費——多加的Consumer只能用于容錯）。

Guarantees

Kafka高級API中提供一些能力：

被一個Producer發(fā)送到特定Topic分區(qū)的消息將按照他們的發(fā)送順序被添加到日志中。這意味著，如果M1、M2是被同一個Producer發(fā)送出來的，且M1先發(fā)送，那么M1擁有更小的Offset，在日志中的位置更靠前。

Consumer按照消息的存儲順序在日志文件中查找消息。

對于復制配置參數(shù)為N的Topic，我們能容忍N-1的服務器故障，而不會丟失已經(jīng)Commit的數(shù)據(jù)。有關這些保證更詳細的信息，參見文檔的設計部分。

Kafka as a Messaging System

Kafka的流模式和傳統(tǒng)的消息系統(tǒng)有什么區(qū)別？

消息傳統(tǒng)上有兩種模式：隊列和發(fā)布-訂閱。在隊列中，一群Consumer從一個Server讀取數(shù)據(jù)，每條消息被其中一個Consumer讀取。在發(fā)布-訂閱中，消息被廣播給所有的Consumer。這兩種模式有各自的優(yōu)缺點。隊列模式的優(yōu)點是你可以在多個消費者實例上分配數(shù)據(jù)處理，從而允許你對程序進行“伸縮”。確定是隊列不是多用戶的，一旦消息被一個Consumer讀取就不會再給其他Consumer。發(fā)布訂閱模式允許廣播數(shù)據(jù)到多個Consumer，那么就沒辦法對單個Consumer進行伸縮。

Kafka的Consumer group包含兩個概念。與隊列一樣，消費組允許通過一些進程來劃分處理（每個進程處理一部分）。與發(fā)布訂閱一樣，Kafka允許廣播消息到不同的Consumer group。

Kafka模式的優(yōu)勢是每個Topic都擁有隊列和發(fā)布-訂閱兩種模式。

Kafka比傳統(tǒng)的消息系統(tǒng)有更強的順序保證。

傳統(tǒng)的消息系統(tǒng)在服務器上按順序保存消息，如果多個Consumer從隊列中消費消息，服務器按照存儲的順序輸出消息。然后服務器雖然按照順序輸出消息，但是消息將被異步的傳遞給Consumer，所以他們將以不確定的順序到達Consumer。這意味著在并行消費中將丟失消息順序。傳統(tǒng)消息系統(tǒng)通常采用“唯一消費者”的概念只讓一個Consumer進行消費，但這就丟失了并行處理的能力。

Kafka做的更好一些。通過提供分區(qū)的概念，Kafka能提供消費集群順序和負載的平衡。這是通過將分區(qū)分配個一個Consumer group中唯一的一個Consumer而實現(xiàn)的，一個分區(qū)只會被一個分組中的一個Consumer進行消費。通過這么實現(xiàn)，能讓一個Consumer消費一個分區(qū)并按照順序處理消息。因為存在多個分區(qū)，所有可以在多個Consumer實例上實現(xiàn)負載均衡。注意，一個分組內(nèi)的Consumer實例數(shù)不能超過分區(qū)數(shù)。

Kafka as a Storage System

任何將發(fā)送消息和消費結構的消息隊列都有效的用作一個消息的存儲系統(tǒng)。不同的是Kafka是一個更好的存儲系統(tǒng)。

被寫入到Kafka的數(shù)據(jù)將被寫入磁盤并復制以保證容錯。Kafka允許Producer等待確定，以保證Producer可以確認消息被成功持久化并復制完成。

Kafka使用的存儲結構，使其提供相同的能力，無論是存儲50KB或者50TB持久化數(shù)據(jù)。

因為允許客戶端控制讀取的位置，可以將Kafka視為高性能，低延遲的日志存儲、復制、傳播的分布式系統(tǒng)。

Kafka for Stream Processing

僅僅是讀寫和存儲流數(shù)據(jù)是不夠的，Kafka的目標是對流失數(shù)據(jù)的實時處理。

在Kafka中，Stream Producer從輸入的Topic中讀取數(shù)據(jù)，執(zhí)行一些操作，生成輸出流到輸出的Topic中。

例如，零售的應用程序?qū)⑹盏戒N售和出貨的輸入流，并輸出根據(jù)該數(shù)據(jù)計算的重排序和價格調(diào)整后的數(shù)據(jù)流。

可以使用Producer和Consumer實現(xiàn)簡單的處理。對于更復雜的轉(zhuǎn)換，Kafka提供的完成的Stream API，允許構建將流中數(shù)據(jù)聚合或?qū)⒘鬟B接到一起的應用。

這用于解決以下的一些困難：處理無需的數(shù)據(jù)，執(zhí)行有狀態(tài)的計算等。

Stream API基于Kafka的核心函數(shù)古劍：使用Producer和Consumer API用于輸入，使用Kafka作為有狀態(tài)的存儲，使用group機制來實現(xiàn)Stream處理器的容錯。

Putting the Pieces Together

消息、存儲和流處理這種組合看是不尋常，但是Kafka作為流式平臺這是必須的。

類似HDFS的分布式文件系統(tǒng)存儲靜態(tài)的文件用于批處理。這種的系統(tǒng)允許存儲和處理歷史數(shù)據(jù)。

傳統(tǒng)的企業(yè)消息系統(tǒng)允許處理在你訂閱之后的未來的數(shù)據(jù)。以這種方式構建的應用程序在未來數(shù)據(jù)到達時進行處理。

Kafka組合這些能力，并且組合這些對Kafka作為流應用平臺和流數(shù)據(jù)通道至關重要。

通過組合存儲和低延遲的訂閱，流應用程序能以相同的方式處理過去和未來的數(shù)據(jù)。一個單一的程序可以處理過去的歷史數(shù)據(jù)，并且不會在達到一個位置時停止，而是能繼續(xù)處理將來到達的數(shù)據(jù)。這是一個廣泛的流處理的概念，其中包含批處理和消息驅(qū)動的應用程序。

同樣，對于數(shù)據(jù)流通道，組合訂閱機制和實時事件使Kafka成為非常低延遲的管道；數(shù)據(jù)的存儲能力使其能和可能會進行停機維護的周期性處理數(shù)據(jù)的離線系統(tǒng)集成，或用于必須保證數(shù)據(jù)被確認交付的場景。流處理程序可以在數(shù)據(jù)到達后進行處理。

其他關閉Kafka提供的API、功能，參閱其他文檔。

?

------------------------------------------------------------------------------

?

下面是博主的公眾號，后續(xù)會發(fā)布和討論一系列分布式消息隊列相關的內(nèi)容，歡迎關注。

如果本文對您有幫助，點一下右下角的“推薦”

總結

以上是生活随笔為你收集整理的Kafka官方文档翻译——简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。