[[408780]]

概念

• Kafka 是一種高吞吐量、分布式、基于發(fā)布/訂閱的消息系統(tǒng)，最初由 LinkedIn 公司開發(fā)，使用 Scala (JAVA)語言編寫，目前是Apache 的開源項目。
• 主要解決應(yīng)用解耦、異步消息、流量削峰等問題。
• Kafka實(shí)際上也是一個主從架構(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實(shí)現(xiàn)，利用了zookeeper的znode模型與監(jiān)聽機(jī)制。

控制器故障轉(zhuǎn)移

存在單點(diǎn)故障，但是每個broker節(jié)點(diǎn)都可以成為controller;

故障轉(zhuǎn)移即failover也是基于zookeeper實(shí)現(xiàn)的，znode模型與監(jiān)聽機(jī)制，/controller節(jié)點(diǎn)。

kafka和zookeeper如何配合工作

1. kafka嚴(yán)重依賴于zookeeper集群。
2. 所有的broker在啟動的時候都會往zookeeper進(jìn)行注冊，目的就是選舉出一個controller
3. 選舉過程非常簡單粗暴，就是一個誰先誰當(dāng)?shù)倪^程，不涉及什么算法問題。
4. 成為controller之后，它會監(jiān)聽zookeeper里面的多個目錄.
5. 注冊時各個節(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個問題：

1. 觸發(fā)重新選舉
2. 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é)實(shí)現(xiàn)在集群中多個 Broker 之間分配分區(qū)(即日志)、分配領(lǐng)導(dǎo)權(quán)、處理故障等分布式系統(tǒng)的功能。而早已經(jīng)過業(yè)界廣泛使用和驗(yàn)證過的 ZooKeeper 是分布式代碼工作的關(guān)鍵部分。

假設(shè)沒有 ZooKeeper 的話，Kafka 甚至無法啟動進(jìn)程，但嚴(yán)重依賴 ZooKeeper，也給 Kafka 帶來了掣肘。

不過目前大部分用的還是和zk結(jié)合版本的kafka。