Kafka基礎教程

kafka最早是linkedin公司用於日誌處理的分布式訊息佇列。現在它的功能遠不止訊息佇列這麼簡單。根據kafka官網的定義，kafka是乙個分布式的流處理平台。它擁有以下三大核心功能：

發布和訂閱資料流，類似於傳統訊息佇列（rabbitmq，rocketmq）的功能以容錯的方式儲存資料流的功能

實時處理資料流的功能

為了支援以上的三大核心功能，kafka擁有四組核心api，包括：

producer api：用於傳送資料。 consumer api：用於消費資料。 streams api：用於流處理，接受乙個輸入流資料經過計算後產生乙個輸出流資料。

connector api：用於連線外部應用從而構建乙個可重用的producer或consumer。例如，可以通過connnetcor自動捕獲資料庫中資料的每一次變更。

下面的這張圖闡述了kafka目前的所有核心功能：

kafka-apis.png

基礎概念

下面是乙個訊息系統中的一些基本概念：

topic：主題，它代表著訊息的類別。發布者發布一條訊息必須指定topic，訂閱者通過訂閱topic就能消費此訊息。 producer：訊息傳送者。我們將發布訊息到topic的程序叫做producer。 consumer: 訊息消費者。我們將訂閱topic，獲取訊息的程序叫做consumer。kafka中的consumer採用poll模型。

broker：kafka集群中的每一台伺服器。kafka是乙個分布式集群，我們將其中每一台伺服器都叫做broker。

producer和consumer通過tcp協議與kafka集群通訊，producer和consumer可以看作是kafka集群的客戶端。producer通過tcp協議傳送訊息到kafka集群，kafka集群再將這些訊息提供給consumer。如下圖所示：

kafka cluster.png

topic

topic是代表著資料的類別。乙個topic可以認為是一類訊息。producer在傳送訊息時必須指定發往哪個topic，此後，訂閱了該topic的所有consumer都能夠接收到訊息。

log_anatomy.png

producer傳送訊息時可以顯示地指定對應topic的partition號，從而將訊息儲存在特定的partition中。

kafka將topic劃分為多個partition進行儲存擁有兩個好處：

訊息儲存擴容。乙個檔案的儲存大小是有限的，但在集群中的多個檔案的儲存就可以大大增加乙個topic能夠儲存的訊息數量。

並行讀寫。通過多個partition檔案儲存訊息，意味著producer和consumer可以並行的讀寫乙個topic。

consumer消費訊息時，通過指定的offset來定位下一條要讀取的訊息。kafka集群只負責根據consumer傳入的offset來返回對應的訊息。如下圖所示：

log_consumer.png

kafka不會立刻刪除已經被消費的訊息，它會根據broker中的配置來決定多久清理一次。當broker中配置的時間到達時，不論訊息是否被消費，kafka都會清理磁碟空間。

producer

producer負責將訊息傳送到kafka集群的某乙個topic中。同時producer傳送訊息時能夠指定partition號，從而將訊息持久化到特定的partition中。

如果沒有指定具體的partition號，那麼kafka producer可以通過一定的演算法計算出對應的partition號。具體演算法如下：

如果待傳送的訊息指定了key，則對key進行hash然後對映到對應的partition號如果待傳送的訊息沒有指定key，則使用round robin輪詢演算法來確定partition號。這樣可以保證資料在所有的partition上平均分配。

另外，kafka producer也支援自定義的partition分配方式。客戶端提供乙個實現了org.apache.kafka.clients.producer.partitioner的類，然後將此實現類配置到producer中即可。

consumer

kafka中的每個partition都由一系列有序的、不可變的訊息組成，這些訊息被連續的追加到partition中。partition中的每個訊息都有乙個連續的序列號叫做offset，用於partition唯一標識一條訊息。

consumer通過移動offset來順序讀取訊息。在kafka 0.9前，offset資訊儲存在zookeeper的[consumers//offsets//]目錄中。而在0.9之後，所有的offset資訊都儲存在了broker上的乙個名為__consumer_offsets的topic中。

傳統的訊息佇列提供兩種訊息消費模式：

佇列模式：一條訊息只能被多個消費者中的乙個消費。

發布訂閱模式：一條訊息能夠被多個消費者同時消費。

kafka為了支援這兩種消費模型，提出了消費者組（consumer group）的概念。如下圖所示：

consumer-groups.png

如圖，每乙個消費者不再是乙個簡單的訂閱了某個topic的個體，多個消費者被放在了乙個消費者組中。每乙個消費者必須屬於乙個消費者組，同時乙個消費者組能夠擁有多個消費者。對於乙個消費者組，kafka擁有以下約束：

一條訊息只能被乙個消費者組中的乙個消費者消費。

同乙個partition中的訊息只能被某個消費者組中的某個固定消費者消費。

在乙個消費者組中，如果有兩個消費者同時訂閱了某個topic，那麼該topic的某條訊息一定只會被其中乙個消費者消費。這就實現了佇列模式。

如果將訂閱了某個topic的兩個消費者放在不同的消費者組下，那麼該topic中的訊息就能被這兩個消費者同時消費。這就實現了發布訂閱模式。

另外，如上圖所示，在乙個消費者組中，一旦某個partition被分配給了某個消費者，那麼該partition就不會再分配給任何其他的同組消費者。因此如果乙個consumer group中消費者數量超過了partition數量，那麼一定會有多餘的消費者永遠收不到訊息。

最後，kafka只能夠保證訊息再乙個分區內的消費是有序的。無法保證乙個topic下（擁有多個分割槽）所有的訊息消費都是有序的。

replication

乙個topic 的多個partition，被分布在kafka 集群中的多個broker上。每個broker負責partition中儲存的訊息的讀寫操作。此外，kafka還支援為每個partition設定需要備份（replicas）的個數，所有的備份partition分布kafka集群中，以提高可用性。

既然kafka支援replication，那麼就意味著需要對多歌備份進行排程。每個partition 都有乙個機器被稱為"leader"，同時零個或多個機器作為follower。leader 負責所有的讀寫操作，follower執行leader的指令。如果leader 失效,那麼將會有其他follower 來接管，成為新的leader。follower只是單調的和leader 跟進同步訊息即可。因此，所有傳送到kafka集群的讀寫請求本質上均是針對leader的操作，leader操作完成後，傳送指令給follower進行資料同步，從而實現了高可用性。

Kafka基礎教程

XSL基礎教程

ps基礎教程

php基礎教程

Kafka基礎教程

XSL基礎教程

ps基礎教程

php基礎教程

相關推薦