基礎(chǔ)概念、架構(gòu)和新版的升級-Kafka知識體系(一)
概念
- Kafka 是一種高吞吐量、分布式、基于發(fā)布/訂閱的消息系統(tǒng),最初由 LinkedIn 公司開發(fā),使用 Scala (JAVA)語言編寫,目前是Apache 的開源項目。
- 主要解決應(yīng)用解耦、異步消息、流量削峰等問題。
- Kafka實際上也是一個主從架構(gòu),有一個Controller角色即控制器,協(xié)調(diào)管理整個集群。
關(guān)鍵術(shù)語
broker
Kafka 服務(wù)器,負(fù)責(zé)消息存儲和轉(zhuǎn)發(fā)。
topic
消息類別,Kafka 按照topic 來分類消息;似于關(guān)系型數(shù)據(jù)庫的表。
partition
topic 的分區(qū),一個 topic 可以包含多個 partition ,topic 消息保存在各個 partition 上。
offset
消息在日志中的位置,可以理解是消息在partition 上的偏移量,也是代表該消息的唯一序號。
Producer
消息生產(chǎn)者,將消息push到Kafka集群中的Broker。
Consumer
消息消費(fèi)者,從Kafka集群中pull消息,消費(fèi)消息。
Consumer Group
消費(fèi)者分組,每個Consumer 必須屬于一個group
Zookeeper
保存著集群broker、topic、partition 等meta 數(shù)據(jù);另外,還負(fù)責(zé)broker 故 障發(fā)現(xiàn),partition leader 選舉,負(fù)載均衡等功能。
從抽象到具體理解Kafka架構(gòu)設(shè)計
從宏觀的層面來理解,它就是一個存儲系統(tǒng)。
細(xì)分一下,又有多個生產(chǎn)者,多個消費(fèi)者,Broker 集群和Kafka 組成。
再次細(xì)分,broker有一個controller角色,每一個broker 可能存多個Topic的不同partion,每個partion 都有 leader 和follower 。這些信息都會注冊到zk上。
集群架構(gòu)的理解及新版優(yōu)化
控制器 controller
我們熟知一個規(guī)律:在大數(shù)據(jù)分布式文件系統(tǒng)里面,95%的都是主從式的架構(gòu),個別是對等式的架構(gòu),比如ElasticSearch。
kafka也是主從式的架構(gòu),主節(jié)點(diǎn)就叫controller,其余的為從節(jié)點(diǎn),controller是需要和zookeeper進(jìn)行配合管理整個kafka集群。
作用
協(xié)調(diào)與管理整個集群。
職責(zé)
- 主題增刪改
- 分區(qū)重分配
- leader選舉
- 元數(shù)據(jù)管理
- broker成員管理,宕機(jī)或加入
控制器選舉
基于zookeeper實現(xiàn),利用了zookeeper的znode模型與監(jiān)聽機(jī)制。
控制器故障轉(zhuǎn)移
存在單點(diǎn)故障,但是每個broker節(jié)點(diǎn)都可以成為controller;
故障轉(zhuǎn)移即failover也是基于zookeeper實現(xiàn)的,znode模型與監(jiān)聽機(jī)制,/controller節(jié)點(diǎn)。
kafka和zookeeper如何配合工作
- kafka嚴(yán)重依賴于zookeeper集群。
- 所有的broker在啟動的時候都會往zookeeper進(jìn)行注冊,目的就是選舉出一個controller
- 選舉過程非常簡單粗暴,就是一個誰先誰當(dāng)?shù)倪^程,不涉及什么算法問題。
- 成為controller之后,它會監(jiān)聽zookeeper里面的多個目錄.
- 注冊時各個節(jié)點(diǎn)必定會暴露自己的主機(jī)名,端口號等等的信息,此時controller就要去讀取注冊上來的從節(jié)點(diǎn)的數(shù)據(jù)(通過監(jiān)聽機(jī)制),生成集群的元數(shù)據(jù)信息,之后把這些信息都分發(fā)給其他的服務(wù)器,讓其他服務(wù)器能感知到集群中其它成員的存在。
新版Kafka將要拋棄ZooKeeper!!!!!!
2021年3月30日,Kafka背后的企業(yè)Confluent發(fā)布博客表示,在即將發(fā)布的 2.8 版本里,用戶可在完全不需要 ZooKeeper 的情況下運(yùn)行 Kafka,該版本將依賴于 ZooKeeper 的控制器改造成了基于 Kafka Raft 的 Quorm 控制器。
在之前的版本中,如果沒有 ZooKeeper,Kafka 將無法運(yùn)行。但管理部署兩個不同的系統(tǒng)不僅讓運(yùn)維復(fù)雜度翻倍,還讓 Kafka 變得沉重,進(jìn)而限制了 Kafka 在輕量環(huán)境下的應(yīng)用,同時 ZooKeeper 的分區(qū)特性也限制了 Kafka 的承載能力。
第一次,用戶可以在沒有 ZooKeeper 的情況下運(yùn)行 Kafka。
這是一次架構(gòu)上的重大升級,讓一向“重量級”的 Kafka 從此變得簡單了起來。輕量級的單進(jìn)程部署可以作為 ActiveMQ 或 RabbitMQ 等的替代方案,同時也適合于邊緣場景和使用輕量級硬件的場景。
為什么要拋棄使用了十年的 ZooKeeper?
zk的缺點(diǎn):
- zookeeper 的一個缺點(diǎn)就是 同步數(shù)據(jù)不能太大。
- zookeeper集群中l(wèi)eader和follower同步數(shù)據(jù)的極限值是500M,這500M的數(shù)據(jù),加載到內(nèi)存中,大約占用3個G的內(nèi)存。
- 數(shù)據(jù)過大,在每次選舉之后,需要從server同步到follower,容易造成下面2個問題:
- 觸發(fā)重新選舉
- io 太久
ZooKeeper 充當(dāng) Kafka 的領(lǐng)導(dǎo)者,以更新集群中的拓?fù)涓?根據(jù) ZooKeeper 提供的通知,生產(chǎn)者和消費(fèi)者發(fā)現(xiàn)整個 Kafka 集群中是否存在任何新 Broker 或 Broker 失敗。大多數(shù)的運(yùn)維操作,比如說擴(kuò)容、分區(qū)遷移等等,都需要和 ZooKeeper 交互。
也就是說,Kafka 代碼庫中有很大一部分是負(fù)責(zé)實現(xiàn)在集群中多個 Broker 之間分配分區(qū)(即日志)、分配領(lǐng)導(dǎo)權(quán)、處理故障等分布式系統(tǒng)的功能。而早已經(jīng)過業(yè)界廣泛使用和驗證過的 ZooKeeper 是分布式代碼工作的關(guān)鍵部分。
假設(shè)沒有 ZooKeeper 的話,Kafka 甚至無法啟動進(jìn)程,但嚴(yán)重依賴 ZooKeeper,也給 Kafka 帶來了掣肘。
不過目前大部分用的還是和zk結(jié)合版本的kafka。