Kafka(一) Kafka集群的搭建與使用

2021-10-07 07:10:36 字數 3093 閱讀 4726

kafka基本概念

kafka是乙個分布式的,分割槽的訊息(官方稱之為commit log)服務。它提供乙個訊息系統應該具備的功能,但是確有著獨特的設計。可以這樣來說,kafka借鑑了jms規範的思想,但是確並沒有完全遵循jms規範。首先,讓我們來看一下基礎的訊息(message)相關術語:

因此,從乙個較高的層面上來看,producer通過網路傳送訊息到kafka集群,然後consumer來進行消費,如下圖:

服務端(brokers)和客戶端(producer、consumer)之間通訊通過tcp協議來完成。

可以這麼來理解topic,partition和broker

乙個topic,代表邏輯上的乙個業務資料集,比如按資料庫裡不同表的資料操作訊息區分放入不同topic,訂單相關操作訊息放入訂單topic,使用者相關操作訊息放入使用者topic,對於大型**來說,後端資料都是海量的,訂單訊息很可能是非常巨量的,比如有幾百個g甚至達到tb級別,如果把這麼多資料都放在一台機器上可定會有容量限制問題,那麼就可以在topic內部劃分多個partition來分片儲存資料,不同的partition可以位於不同的機器上,每台機器上都執行乙個kafka的程序broker。

kafka集群,在配置的時間範圍內,維護所有的由producer生成的訊息,而不管這些訊息有沒有被消費。例如日誌保留(log retention )時間被設定為2天。kafka會維護最近2天生產的所有訊息,而2天前的訊息會被丟棄。kafka的效能與保留的資料量的大小沒有關係,因此儲存大量的資料(日誌資訊)不會有什麼影響。

每個consumer是基於自己在commit log中的消費進度(offset)來進行工作的。在kafka中,消費offset由consumer自己來維護;一般情況下我們按照順序逐條消費commit log中的訊息,當然我可以通過指定offset來重複消費某些訊息,或者跳過某些訊息。

這意味kafka中的consumer對集群的影響是非常小的,新增乙個或者減少乙個consumer,對於集群或者其他consumer來說,都是沒有影響的,因為每個consumer維護各自的offset。所以說kafka集群是無狀態的,效能不會因為consumer數量受太多影響。kafka還將很多關鍵資訊記錄在zookeeper裡,保證自己的無狀態,從而在水平擴容時非常方便。

為什麼要對topic下資料進行分割槽儲存?

1、commit log檔案會受到所在機器的檔案系統大小的限制,分割槽之後,理論上乙個topic可以處理任意數量的資料。

2、為了提高並行度。

分布式distribution

log的partitions分布在kafka集群中不同的broker上,每個broker可以請求備份其他broker上partition上的資料。kafka集群支援配置乙個partition備份的數量。

針對每個partition,都有乙個broker起到「leader」的作用,0個或多個其他的broker作為「follwers」的作用。leader處理所有的針對這個partition的讀寫請求,而followers被動複製leader的結果。如果這個leader失效了,其中的乙個follower將會自動的變成新的leader。

producers

生產者將訊息傳送到topic中去,同時負責選擇將message傳送到topic的哪乙個partition中。通過round­robin做簡單的負載均衡。也可以根據訊息中的某乙個關鍵字來進行區分。通常第二種方式使用的更多。

consumers

傳統的訊息傳遞模式有2種:佇列( queue) 和(publish-subscribe)

queue模式:多個consumer從伺服器中讀取資料,訊息只會到達乙個consumer。

publish-subscribe模式:訊息會被廣播給所有的consumer。

kafka基於這2種模式提供了一種consumer的抽象概念:consumer group。

queue模式:所有的consumer都位於同乙個consumer group 下。

publish-subscribe模式:所有的consumer都有著自己唯一的consumer group。

上圖說明:由2個broker組成的kafka集群,總共有4個partition(p0-p3)。這個集群由2個consumer group, a有2個consumer instances ,b有四個。

通常乙個topic會有幾個consumer group,每個consumer group都是乙個邏輯上的訂閱者(logicalsubscriber )。每個consumer group由多個consumer instance組成,從而達到可擴充套件和容災的功能

消費順序

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

乙個partition同乙個時刻在乙個consumer group中只有乙個consumer instance在消費,從而保證順序。consumer group中的consumer instance的數量不能比乙個topic中的partition的數量多,否則,多出來的consumer消費不到訊息。

kafka只在partition的範圍內保證訊息消費的區域性順序性,不能在同乙個topic中的多個partition中保證總的消費順序性。

如果有在總體上保證消費順序的需求,那麼我們可以通過將topic的partition數量設定為1,將consumer group中的consumer instance數量也設定為1。

從較高的層面上來說的話,kafka提供了以下的保證:

傳送到乙個topic中的message會按照傳送的順序新增到commit log中。意思是,如果訊息 m1,m2由同乙個producer傳送,m1比m2傳送的早的話,那麼在commit log中,m1的offset就會比commit 2的offset小。

乙個consumer在commit log中可以按照傳送順序來消費message。如果乙個topic的備份因子設定為n,那麼kafka可以容忍n-1個伺服器的失敗,而儲存在commit log中的訊息不會丟失。

kafka集群輸出到elk集群,分析顯示搭建

zk 3個服務分別在三個主機上,kafka服務3個同上,elasticsearch服務3個同上,以上三個服務配置檔案在三颱機器上基本一樣,只需改一下ip等資訊。logstash乙個在131,kibana1個在131 zk配置 zoo.cfg zk bin zkserver.sh start tick...

kafka學習 四 kafka集群部署

1 broker.id 1 保證每個broker唯一,第一台可以不修改預設為0,後面兩台需要修改,如改為2和3 2 num.partitions 3 分割槽數量一般與broker保持一致 3 listeners plaintext 192.168 172 129 9092 修改為本機ip 4 zoo...

kafka 集群 測試

參考資料 wget 解壓tar xvzf kafka 2.11 0.10.0.1.tgz 移動mv kafka 2.11 0.10.0.1 usr local 修改配置 cd kafka 2.11 0.10.0.1 config mv server.properties server 1.prope...