zookeeper + kafka集群搭建详解
文章目錄
- 一、消息隊(duì)列介紹
- 1.1 為什么需要消息隊(duì)列 （MO）
- 1.2 使用消息隊(duì)列的好處
- （1）解耦
- （2）可恢復(fù)性
- （3）緩沖
- （4）靈活性 & 峰值處理能力
- （5）異步通信很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制， 允許用戶把一個消息放入隊(duì)列， 但并不立即處理它。 想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。
- 1.3 消息隊(duì)列的兩種模式
- （1）點(diǎn)對點(diǎn)模式（一對一，消費(fèi)者主動拉取數(shù)據(jù)，消息收到后消息清除）
- （2）發(fā)布/訂閱模式（一對多， 又叫觀察者模式，消費(fèi)者消費(fèi)數(shù)據(jù)之后不會清除消息）
- 二、Kafka相關(guān)介紹
- 2.1 Kafka定義
- 2.2 Kafka簡介
- 2.3 Kafka的特性
- 三、Kafka系統(tǒng)架構(gòu)
- 3.1 Broker
- 3.2 Topic
- 3.3 Partition
- 3.4 Leader
- 3.5 Follower
- 3.7 Producer
- 3.8 Consumer
- 3.9 Consumer Group (CG )
- 3.10 offset偏移量
- 3.11 Zookeeper
- 四、部署zookeeper + kafka 集群
- 4.1 部署zookeeper + kafka 集群的具體實(shí)驗(yàn)步驟
- 1.檢查之前zookeeper集群的狀態(tài)，
- 2.在/opt目錄下放入安裝包，解壓
- 3.移動并將配置文件進(jìn)行備份
- 4.設(shè)置環(huán)境變量
- 5.配置 Zookeeper 啟動腳本
- 6.設(shè)置開機(jī)自啟并啟動
- 測試階段：
- 1.創(chuàng)建topic
- 2.查看當(dāng)前服務(wù)器中的所有 topic
- 3.發(fā)布消息
- 4.消費(fèi)消息
- 五、部署 Filebeat+Kafka+ELK
- 5.1 部署 Filebeat+Kafka+ELK的具體實(shí)驗(yàn)步驟
- 1.部署 Zookeeper+Kafka 集群
- 2.部署 Filebeat
- ① 兩個node服務(wù)器狀態(tài)如下：
- ② Apache服務(wù)器狀態(tài)如下：
- 3.在node1服務(wù)器上對接kafka（因?yàn)橹霸趎ode1上做的filebeat）
- ① 安裝httpd服務(wù)，后面要收集node1的Apache訪問日志。
- ② 開啟httpd服務(wù)
- ③ 修改日志采集路徑
- ④啟動 filebeat
- 4.部署 ELK，在 Logstash 組件所在節(jié)點(diǎn)上新建一個 Logstash 配置文件（192.168.153.80）
- ①修改配置文件
- ② 啟動
- ③ 使用宿主機(jī)訪問node1的Apache首頁
- ④ 在node1上可以看到數(shù)據(jù)正在接受，剛剛訪問的日志也可以看到
一、消息隊(duì)列介紹
1.1 為什么需要消息隊(duì)列 （MO）
主要原因是由于在高并發(fā)環(huán)境下，同步請求來不及處理，請求往往會發(fā)生阻塞。比如大量的請求并發(fā)訪問數(shù)據(jù)庫，導(dǎo)致行鎖表鎖，最后請求線程會堆積過多， 從而觸發(fā) too many connection 錯誤， 引發(fā)雪崩效應(yīng)。
我們使用消息隊(duì)列，通過異步處理請求，從而緩解系統(tǒng)的壓力。消息隊(duì)列常應(yīng)用于異步處理，流量削峰，應(yīng)用解耦，消息通訊等場景當(dāng)前比較常見的 MQ 中間件有 ActiveMQ、RabbitMQ、RocketMQ、Kafka 等。
1.2 使用消息隊(duì)列的好處
（1）解耦
允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程， 只要確保它們遵守同樣的接口約束。
（2）可恢復(fù)性
系統(tǒng)的一部分組件失效時(shí)，不會影響到整個系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可 以在系統(tǒng)恢復(fù)后被處理。
（3）緩沖
有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度，解決生產(chǎn)消息和消費(fèi)消息的處理速度不一致的情況。
（4）靈活性 & 峰值處理能力
在訪問量劇增的情況下， 應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見。 如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時(shí)待命無疑是巨大的浪費(fèi)。 使用消息隊(duì)列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力， 而不會因?yàn)橥话l(fā)的超負(fù)荷的請求而完全崩潰。
（5）異步通信很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制， 允許用戶把一個消息放入隊(duì)列， 但并不立即處理它。 想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。
1.3 消息隊(duì)列的兩種模式
（1）點(diǎn)對點(diǎn)模式（一對一，消費(fèi)者主動拉取數(shù)據(jù)，消息收到后消息清除）
消息生產(chǎn)者生產(chǎn)消息發(fā)送到消息隊(duì)列中， 然后消息消費(fèi)者從消息隊(duì)列中取出并且消費(fèi)消息。 消息被消費(fèi)以后， 消息隊(duì)列中不再有存儲，所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。消息隊(duì)列支持存在多個消費(fèi)者， 但是對一個消息而言，只會有一個消費(fèi)者可以消費(fèi)。
（2）發(fā)布/訂閱模式（一對多， 又叫觀察者模式，消費(fèi)者消費(fèi)數(shù)據(jù)之后不會清除消息）
消息生產(chǎn)者 （發(fā)布）將消息發(fā)布到 topic 中，同時(shí)有多個消息消費(fèi)者 （訂閱）消費(fèi)該消息。和點(diǎn)對點(diǎn)方式不同，發(fā)布到 topic 的消息會被所有訂閱者消費(fèi)。
發(fā)布/訂閱模式是定 義對象間一種—對多的依賴關(guān)系，使得每當(dāng)一個對象 （ 目標(biāo)對象）的狀態(tài)發(fā)生改變， 則所有依賴干它的對象 （觀察者對象）都會得到通知并自動更新。
二、Kafka相關(guān)介紹
2.1 Kafka定義
Kafka 是一個分布式的基于發(fā)布/訂閱模式的消息隊(duì)列（MQ，Message Queue），主要應(yīng)用于大數(shù)據(jù)實(shí)時(shí)處理領(lǐng)域。
2.2 Kafka簡介
Kafka 是最初由 Linkedin 公司開發(fā)，是一個分布式、支持分區(qū)的（partition）、多副本的（replica），基于 Zookeeper協(xié)調(diào)的分布式消息中間件系統(tǒng)，它的最大的特性就是可以實(shí)時(shí)的處理大量數(shù)據(jù)以滿足各種需求場景，比如基于 hadoop的批處理系統(tǒng)、低延遲的實(shí)時(shí)系統(tǒng)、Spark/Flink 流式處理引擎，nginx 訪問日志，消息服務(wù)等等，用 scala 語言編寫， Linkedin 于 2010 年貢獻(xiàn)給了 Apache 基金會并成為頂級開源項(xiàng)目。
2.3 Kafka的特性
高吞吐量、低延遲
Kafka 每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒。每個 topic 可以分多個 Partition，Consumer Group 對 Partition 進(jìn)行消費(fèi)操作，提高負(fù)載均衡能力和消費(fèi)能力。
可擴(kuò)展性
kafka 集群支持熱擴(kuò)展
持久性、可靠性
消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失
容錯性
允許集群中節(jié)點(diǎn)失敗（多副本情況下，若副本數(shù)量為 n，則允許 n-1 個節(jié)點(diǎn)失敗）
高并發(fā)
支持?jǐn)?shù)干個客戶端同時(shí)讀寫
三、Kafka系統(tǒng)架構(gòu)
3.1 Broker
一臺 kafka 服務(wù)器就是一個 broker。一個集群由多個 broker 組成。一個 broker 可以容納多個 topic。
3.2 Topic
可以理解為一個隊(duì)列，生產(chǎn)者和消費(fèi)者面向的都是一個 topic。類似于數(shù)據(jù)庫的表名或者 ES 的 index物理上不同 topic 的消息分開存儲。
3.3 Partition
為了實(shí)現(xiàn)擴(kuò)展性，一個非常大的 topic 可以分布到多個 broker （即服務(wù)器）上，一個 topic 可以分割為一個或多個 partition，每個 partition 是一個有序的隊(duì)列。Kafka 只保證 partition 內(nèi)的記錄是有序的，而不保證 topic 中不同 partition 的順序。
每個 topid 至少有一個
partition，當(dāng)生產(chǎn)者產(chǎn)生數(shù)據(jù)的時(shí)候，會根據(jù)分配策略選擇分區(qū)，然后將消息追加到指定的分區(qū)的隊(duì)列末尾。##Partation 數(shù)據(jù)路由規(guī)則;
1.指定了patition，則直接使用;
2．未指定 patition 但指定 key（相當(dāng)于消息中某個屬性），通過對 key 的 value 進(jìn)行 hash 取模，選出一個 patition;
4. patition 和 key 都未指定，使用輪詢選出一個 patition。
5.
每條消息都會有一個自增的編號，用于標(biāo)識消息的偏移量，標(biāo)識順序從 0 開始。每個 partition 中的數(shù)據(jù)使用多個 segment 文件存儲。
如果 topic 有多個 partition，消費(fèi)數(shù)據(jù)時(shí)就不能保證數(shù)據(jù)的順序
。嚴(yán)格保證消息的消費(fèi)順序的場景下 （例如商品秒殺、搶紅包）， 需要將 partition 數(shù)目設(shè)為 1。
broker 存儲 topic 的數(shù)據(jù)。如果某 topic 有 N 個 partition，集群有 N 個 broker，那么每個 broker 存儲該 topic的一個 partition。
如果某 topic 有 N 個 partition，集群有（N+M）個 broker，那么其中有 N 個 broker 存儲 topic 的一個 partition剩下的 M 個 broker 不存儲該 topic 的 partition 數(shù)據(jù)。
如果某 topic 有 N 個 partition，集群中 broker 數(shù)目少于 N 個，那么一個 broker 存儲該 topic 的一個或多個 partition。在實(shí)際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導(dǎo)致 Kafka 集群數(shù)據(jù)不均衡。
分區(qū)的原因
方便在集群中擴(kuò)展，每個Partition可以通過調(diào)整以適應(yīng)它所在的機(jī)器，而一個topic又可以有多個Partition組成，因此整群就可以適應(yīng)任意大小的數(shù)據(jù)了;
可以提高并發(fā)，因?yàn)榭?以以Partition為單位讀寫了。
3.4 Leader
每個 partition 有多個副本，其中有且僅有一個作為 Leader，Leader 是當(dāng)前負(fù)責(zé)數(shù)據(jù)的讀寫的 partition。
3.5 Follower
Follower 跟隨 Leader，所有寫請求都通過 Leader 路由，數(shù)據(jù)變更會廣播給所有 Follower，Follower 與 Leader保持?jǐn)?shù)據(jù)同步。Follower 只負(fù)責(zé)備份，不負(fù)責(zé)數(shù)據(jù)的讀寫。如果 Leader 故障，則從 Follower 中選舉出一個新的 Leader。
如果 Leader 故障，則從 Follower 中選舉出一個新的 Leader。
當(dāng) Follower 掛掉、卡住或者同步太慢，Leader 會把這個 Follower 從 ISR（Leader 維護(hù)的一個和 Leader 保持同步的 Follower 集合） 列表中刪除，重新創(chuàng)建一個 Follower。
3.6 Replica
副本，為保證集群中的某個節(jié)點(diǎn)發(fā)生故障時(shí)，該節(jié)點(diǎn)上的 partition 數(shù)據(jù)不丟失，且 kafka 仍然能夠繼續(xù)工作，kafka提供了副本機(jī)制，一個 topic 的每個分區(qū)都有若干個副本，一個 leader 和若干個 follower
3.7 Producer
生產(chǎn)者即數(shù)據(jù)的發(fā)布者，該角色將消息發(fā)布到 Kafka 的 topic 中。
broker 接收到生產(chǎn)者發(fā)送的消息后，broker 將該消息追加到當(dāng)前用于追加數(shù)據(jù)的 segment 文件中。生產(chǎn)者發(fā)送的消息，存儲到一個 partition 中，生產(chǎn)者也可以指定數(shù)據(jù)存儲的 partition。
3.8 Consumer
消費(fèi)者可以從 broker 中讀取數(shù)據(jù)。消費(fèi)者可以消費(fèi)多個 topic 中的數(shù)據(jù)。
3.9 Consumer Group (CG )
消費(fèi)者組，由多個consumer 組成。
所有的消費(fèi)者都屬于某個消費(fèi)者組，即消費(fèi)者組是邏輯上的一個訂閱者。可為每個消費(fèi)者指定組名，若不指定組名則屬于默認(rèn)的
將多個消費(fèi)者集中到一起去處理某-一個Topic的數(shù)據(jù)，可以更快的提高數(shù)據(jù)的消費(fèi)能力。
消費(fèi)者組內(nèi)每個消費(fèi)者負(fù)責(zé)消費(fèi)不同分區(qū)的數(shù)據(jù)，一個分區(qū)只能由-一個組內(nèi)消費(fèi)者消費(fèi)，防止數(shù)據(jù)被重復(fù)讀取。
消費(fèi)者組之間互不影響。
3.10 offset偏移量
以唯一的標(biāo)識一條消息。
偏移量決定讀取數(shù)據(jù)的位置，不會有線程安全的問題，消費(fèi)者通過偏移量來決定下次讀取的消息（即消費(fèi)位置）。消息被消費(fèi)之后，并不被馬上冊除，這樣多個業(yè)務(wù)就可以重復(fù)使用 Kafka 的消息。某一個業(yè)務(wù)也可 以通過修改偏移量達(dá)到重新讀取消息的目的，偏移量由用戶控制。消息最終還是會被刪除的，默認(rèn)生命周期為 1 周 （7*24小時(shí)）。
3.11 Zookeeper
Kafka 通過 Zookeeper 來存儲集群中各組件的 meta 信息（元信息）。
由于consumer在消費(fèi)過程中可能會出現(xiàn)斷電宕機(jī)等故障，consumer恢復(fù)后，需要從故障前的位置的繼續(xù)消費(fèi)，所以consumer需要實(shí)時(shí)記錄自己消費(fèi)到了哪個offset，以便故障恢復(fù)后繼續(xù)消費(fèi)。
Kafka 0.9版本之前，consumer 默認(rèn)將offset 保存在Zookeeper 中;
從0.9版本開始，consumer默認(rèn)將offset 保存在Kafka 一個內(nèi)置的topic 中，該topic 為_consumer_ offsets。
四、部署zookeeper + kafka 集群
4.1 部署zookeeper + kafka 集群的具體實(shí)驗(yàn)步驟
1.檢查之前zookeeper集群的狀態(tài)，
由于步驟相同，我這里只展示一臺設(shè)備的搭建！！
2.在/opt目錄下放入安裝包，解壓
3.移動并將配置文件進(jìn)行備份
//修改配置文件
4.設(shè)置環(huán)境變量
5.配置 Zookeeper 啟動腳本
6.設(shè)置開機(jī)自啟并啟動
測試階段：
1.創(chuàng)建topic
2.查看當(dāng)前服務(wù)器中的所有 topic
//查看某個 topic 的詳情
3.發(fā)布消息
4.消費(fèi)消息
153.90服務(wù)器沒先開啟了消費(fèi)消息，所以不能保證順序顯示消息，都能接收到
153.110服務(wù)器是發(fā)布消息后才開啟了消費(fèi)消息，所以可以不能保證順序顯示消息
五、部署 Filebeat+Kafka+ELK
5.1 部署 Filebeat+Kafka+ELK的具體實(shí)驗(yàn)步驟
1.部署 Zookeeper+Kafka 集群
參考上一個實(shí)驗(yàn)，filebeat+kafka已經(jīng)部署完成。
2.部署 Filebeat
之前博客寫過ELK的搭建，具體參考此篇博客：ELK 企業(yè)級日志分析系統(tǒng)，現(xiàn)在來檢查一下ELK集群的狀態(tài)。
① 兩個node服務(wù)器狀態(tài)如下：
② Apache服務(wù)器狀態(tài)如下：
3.在node1服務(wù)器上對接kafka（因?yàn)橹霸趎ode1上做的filebeat）
① 安裝httpd服務(wù)，后面要收集node1的Apache訪問日志。
② 開啟httpd服務(wù)
③ 修改日志采集路徑
④啟動 filebeat
4.部署 ELK，在 Logstash 組件所在節(jié)點(diǎn)上新建一個 Logstash 配置文件（192.168.153.80）
①修改配置文件
② 啟動
③ 使用宿主機(jī)訪問node1的Apache首頁
④ 在node1上可以看到數(shù)據(jù)正在接受，剛剛訪問的日志也可以看到
總結(jié)
以上是生活随笔為你收集整理的zookeeper + kafka集群搭建详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式系统的可靠协调系统——Zookee
- 下一篇： Zabbix监控，详细部署