柚子快報激活碼778899分享：分布式 Kafka之集群搭建

http://yzkb.51969.com/

1. 為什么要使用kafka集群

????????單機服務下，Kafka已經(jīng)具備了非常高的性能。TPS能夠達到百萬級別。但是，在實際工作中使用時，單機搭建的Kafka會有很大的局限性。

????????? 消息太多，需要分開保存。Kafka是面向海量消息設計的，一個Topic下的消息會非常多，單機服務很難存得下來。這些消息就需要分成不同的Partition，分布到多個不同的Broker上。這樣每個Broker就只需要保存一部分數(shù)據(jù)。這些分區(qū)的個數(shù)就稱為分區(qū)數(shù)。? ??????服務不穩(wěn)定，數(shù)據(jù)容易丟失。單機服務下，如果服務崩潰，數(shù)據(jù)就丟失了。為了保證數(shù)據(jù)安全，就需要給每個Partition配置一個或多個備份，保證數(shù)據(jù)不丟失。Kafka的集群模式下，每個Partition都有一個或多個備份。Kafka會通過一個統(tǒng)一的Zookeeper集群作為選舉中心，給每個Partition選舉出一個主節(jié)點Leader，其他節(jié)點就是從節(jié)點Follower。主節(jié)點負責響應客戶端的具體業(yè)務請求，并保存消息。而從節(jié)點則負責同步主節(jié)點的數(shù)據(jù)。當主節(jié)點發(fā)生故障時，Kafka會選舉出一個從節(jié)點成為新的主節(jié)點。????????Kafka集群中的這些Broker信息，包括Partition的選舉信息，都會保存在額外部署的Zookeeper集群當中，這樣，kafka集群就不會因為某一些Broker服務崩潰而中斷。

2. kafka的集群架構

? ? ? ? 由章節(jié)1中對kafka集群特點的描述，我們可以大致畫出kafka的集群架構圖大致如下：

3. kafka集群搭建

? ? ? 接下來我們就動手部署一個Kafka集群，來體驗一下Kafka是如何面向海量數(shù)據(jù)進行橫向擴展的。

3.1 搭建kafka集群

搭建環(huán)境：

1. 準備3臺虛擬機

2.??安裝jdk

????????jdk安裝可參考Linux環(huán)境下安裝JDK-CSDN博客

3. 關閉防火墻（實驗版本關閉防火墻，生產(chǎn)環(huán)境開啟對應端口即可）

firewall-cmd --state 查看防火墻狀態(tài)

systemctl stop firewalld.service 關閉防火墻

?第一步：?zookeeper 集群搭建

? ? ? ? kafka依賴于zookeeper,雖然kafka內部自帶了一個zookeeper,為了保證服務之間的獨立性，不建議使用其內部的zookeeper，所以我們先搭建一個獨立的zookeeper集群。Zookeeper是一種多數(shù)同意的選舉機制，允許集群中少數(shù)節(jié)點出現(xiàn)故障。因此，在搭建集群時，通常都是采用3，5，7這樣的奇數(shù)節(jié)點，這樣可以最大化集群的高可用特性。

????????zk集群搭建參考：zookeeper之集群搭建-CSDN博客

根據(jù)上述文章搭建完成之后，啟動zookeeper集群

第二步： 部署kafka集群

????????kafka服務并不需要進行選舉，因此也沒有奇數(shù)臺服務的建議。

首先，三臺機器都根據(jù)?

初識Kafka-CSDN博客?中的單機服務體驗，上傳、解壓kafka到

解壓到

/app/kafka

目錄下。

? ? ? ? 接下來，進入config目錄，修改server.properties。這個配置文件里面的配置項非常多，下面列出幾個要重點關注的配置

#broker 的全局唯一編號，不能重復，只能是數(shù)字。

broker.id=0

#數(shù)據(jù)文件地址。同樣默認是給的/tmp目錄。

log.dirs=/app/kafka/logs

#默認的每個Topic的分區(qū)數(shù)

num.partitions=1

#zookeeper的服務地址

zookeeper.connect=192.168.31.5:2181,192.168.31.176:2181,192.168.31.232:2181

broker.id需要每個服務器上不一樣，分發(fā)到其他服務器上時，要注意修改一下,比如第一臺是0，第二臺就是1，第三臺的配置就是2。當多個Kafka服務注冊到同一個zookeeper集群上的節(jié)點，會自動組成集群。

server.properties文件中比較重要的核心配置?

?第三步： 啟動kafka集群

bin/kafka-server-start.sh -daemon config/server.properties

-daemon表示后臺啟動kafka服務，這樣就不會占用當前命令窗口。

jps看一下啟動情況：

3.2 搭建中遇到的問題?

3.2.1 啟動時報錯

問題1描述： 啟動kafka時，報沒有與主機關聯(lián)的地址

?問題解決：在hosts文件中追加 127.0.0.1 主機名?localhost?

示例如下：

? ? ? ??

問題2描述： node already exists

問題解決： 檢查kafka集群各個節(jié)點的server.properties，看broker.id有沒有一樣的，各個節(jié)點的broker.id不能重復。

?3.2.1 啟動成功后創(chuàng)建topic報錯

問題描述：執(zhí)行以下命令報連接超時

bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --replication-factor 2 --partitions 4 --topic disTopic

?問題解決：命令中的localhost修改為本機ip,還是報超時；

最終解決,修改每個節(jié)點的server.properties，配置監(jiān)聽

然后執(zhí)行命令時使用主機ip

bin/kafka-topics.sh --bootstrap-server 192.168.31.232:9092 --create --replication-factor 2 --partitions 4 --topic disTopic

創(chuàng)建成功

4.?理解Kafka集群當中核心的Topic、Partition、Broker

????????接下來，我們創(chuàng)建幾個topic,對比單機服務下，理解以下topic、partition和broker。

創(chuàng)建幾個topic：

bin/kafka-topics.sh --bootstrap-server 192.168.31.5:9092 --create --replication-factor 2 --partitions 4 --topic disTopic

列出所有topic：

bin/kafka-topics.sh --bootstrap-server 192.168.31.5:9092 --list __consumer_offsets

查看topic列表情況：

bin/kafka-topics.sh --bootstrap-server 192.168.31.5:9092 --describe -- topic disTopic

1、--create創(chuàng)建，可以指定一些補充的參數(shù)。大部分的參數(shù)都可以在配置文件中指定默認值。

partitons參數(shù)表示分區(qū)數(shù)，這個Topic下的消息會分別存入這些不同的分區(qū)中。示例中創(chuàng)建的disTopic，指定了四個分區(qū)，也就是說這個Topic下的消息會劃分為四個部分。replication-factor表示每個分區(qū)有幾個備份。示例中創(chuàng)建的disTopic，指定了每個partition有兩個備份。

2、--describe查看Topic信息。

partiton參數(shù)列出了四個partition，后面帶有分區(qū)編號，用來標識這些分區(qū)。Leader表示這一組partiton中的Leader節(jié)點是哪一個。這個Leader節(jié)點就是負責響應客戶端請求的主節(jié)點。從這里可以看到，Kafka中的每一個Partition都會分配Leader，也就是說每個Partition都有不同的節(jié)點來負責響應客戶端的請求。這樣就可以將客戶端的請求做到盡量的分散。Replicas參數(shù)表示這個partition的多個備份是分配在哪些Broker上的。也稱為AR。這里的0,1,2就對應配置集群時指定的broker.id。但是，Replicas列出的只是一個邏輯上的分配情況，并不關心數(shù)據(jù)實際是不是按照這個分配。甚至有些節(jié)點服務掛了之后，Replicas中也依然會列出節(jié)點的ID。ISR參數(shù)表示partition的實際分配情況。他是AR的一個子集，只列出那些當前還存活，能夠正常同步數(shù)據(jù)的那些Broker節(jié)點。

?????????接下來，我們還可以查看Topic下的Partition分布情況。在Broker上，與消息，聯(lián)系最為緊密的，其實就是Partition了。之前在配置Kafka集群時，指定了一個log.dirs屬性，指向了一個服務器上的日志目錄。進入這個目錄，就能看到每個Broker的實際數(shù)據(jù)承載情況。

? 從這里可以看到，Broker上的一個Partition對應了日志目錄中的一個目錄。而這個Partition上的所有消息，就保存在這個對應的目錄當中。

????????從整個過程可以看到，Kafka當中，Topic是一個數(shù)據(jù)集合的邏輯單元。同一個Topic下的數(shù)據(jù)，實際上是存儲在Partition分區(qū)中的，Partition就是數(shù)據(jù)存儲的物理單元。而Broker是Partition的物理載體，這些Partition分區(qū)會盡量均勻的分配到不同的Broker機器上。而之前接觸到的offset，就是每個消息在partition上的偏移量。

Kafka為何要這樣來設計Topic、Partition和Broker的關系呢？

1、Kafka設計需要支持海量的數(shù)據(jù)，而這樣龐大的數(shù)據(jù)量，一個Broker是存不下的。那就拆分成多個Partition，每個Broker只存一部分數(shù)據(jù)。這樣極大的擴展了集群的吞吐量。

2、每個Partition保留了一部分的消息副本，如果放到一個Broker上，就容易出現(xiàn)單點故障。所以就給每個Partition設計Follower節(jié)點，進行數(shù)據(jù)備份，從而保證數(shù)據(jù)安全。另外，多備份的Partition設計也提高了讀取消息時的并發(fā)度。

3、在同一個Topic的多個Partition中，會產(chǎn)生一個Partition作為Leader。這個Leader Partition會負責響應客戶端的請求，并將數(shù)據(jù)往其他Partition分發(fā)。

?

5.總結

????????? 經(jīng)過上面的實驗，我們接觸到了很多Kafka中的概念。將這些基礎概念整合起來，就形成了Kafka集群的整體結構。這次我們先把這個整體結構梳理清楚，后續(xù)再一點點去了解其中的細節(jié)。

????????

? 1、Topic是一個邏輯概念，Producer和Consumer通過Topic進行業(yè)務溝通。

? 2、Topic并不存儲數(shù)據(jù)，Topic下的數(shù)據(jù)分為多組Partition，盡量平均的分散到各個Broker上。每組Partition包含Topic下一部分的消息。每組Partition包含一個Leader Partition以及若干個Follower Partition進行備份，每組Partition的個數(shù)稱為備份因子 replica factor。

? 3、Producer將消息發(fā)送到對應的Partition上，然后Consumer通過Partition上的Offset偏移量，記錄自己所屬消費者組Group在當前Partition上消費消息的進度。

? 4、Producer發(fā)送給一個Topic的消息，會由Kafka推送給所有訂閱了這個Topic的消費者組進行處理。但是在每個消費者組內部，只會有一個消費者實例處理這一條消息。

? 5、最后，Kafka的Broker通過Zookeeper組成集群。然后在這些Broker中，需要選舉產(chǎn)生一個擔任Controller角色的Broker。這個Controller的主要任務就是負責Topic的分配以及后續(xù)管理工作。在我們實驗的集群中，這個Controller實際上是通過ZooKeeper產(chǎn)生的。

?

柚子快報激活碼778899分享：分布式 Kafka之集群搭建

http://yzkb.51969.com/

好文閱讀