[[408780]]

概念

• Kafka 是一種高吞吐量、分布式、基于發(fā)布/訂閱的消息系統(tǒng)，最初由 LinkedIn 公司開發(fā)，使用 Scala (JAVA)語(yǔ)言編寫，目前是Apache 的開源項(xiàng)目。
• 主要解決應(yīng)用解耦、異步消息、流量削峰等問(wèn)題。
• Kafka實(shí)際上也是一個(gè)主從架構(gòu)，有一個(gè)Controller角色即控制器，協(xié)調(diào)管理整個(gè)集群。

關(guān)鍵術(shù)語(yǔ)

broker

Kafka 服務(wù)器，負(fù)責(zé)消息存儲(chǔ)和轉(zhuǎn)發(fā)。

topic

消息類別，Kafka 按照topic 來(lái)分類消息;似于關(guān)系型數(shù)據(jù)庫(kù)的表。

partition

topic 的分區(qū)，一個(gè) topic 可以包含多個(gè) partition ，topic 消息保存在各個(gè) partition 上。

offset

消息在日志中的位置，可以理解是消息在partition 上的偏移量，也是代表該消息的唯一序號(hào)。

Producer

消息生產(chǎn)者，將消息push到Kafka集群中的Broker。

Consumer

消息消費(fèi)者，從Kafka集群中pull消息，消費(fèi)消息。

Consumer Group

消費(fèi)者分組，每個(gè)Consumer 必須屬于一個(gè)group

Zookeeper

保存著集群broker、topic、partition 等meta 數(shù)據(jù);另外，還負(fù)責(zé)broker 故 障發(fā)現(xiàn)，partition leader 選舉，負(fù)載均衡等功能。

從抽象到具體理解Kafka架構(gòu)設(shè)計(jì)

從宏觀的層面來(lái)理解，它就是一個(gè)存儲(chǔ)系統(tǒng)。

細(xì)分一下，又有多個(gè)生產(chǎn)者，多個(gè)消費(fèi)者，Broker 集群和Kafka 組成。

再次細(xì)分，broker有一個(gè)controller角色，每一個(gè)broker 可能存多個(gè)Topic的不同partion，每個(gè)partion 都有 leader 和follower 。這些信息都會(huì)注冊(cè)到zk上。

集群架構(gòu)的理解及新版優(yōu)化

控制器 controller

我們熟知一個(gè)規(guī)律：在大數(shù)據(jù)分布式文件系統(tǒng)里面，95%的都是主從式的架構(gòu)，個(gè)別是對(duì)等式的架構(gòu)，比如ElasticSearch。

kafka也是主從式的架構(gòu)，主節(jié)點(diǎn)就叫controller，其余的為從節(jié)點(diǎn)，controller是需要和zookeeper進(jìn)行配合管理整個(gè)kafka集群。

作用

協(xié)調(diào)與管理整個(gè)集群。

職責(zé)

• 主題增刪改
• 分區(qū)重分配
• leader選舉
• 元數(shù)據(jù)管理
• broker成員管理，宕機(jī)或加入

控制器選舉

基于zookeeper實(shí)現(xiàn)，利用了zookeeper的znode模型與監(jiān)聽(tīng)機(jī)制。

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

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

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

kafka和zookeeper如何配合工作

1. kafka嚴(yán)重依賴于zookeeper集群。
2. 所有的broker在啟動(dòng)的時(shí)候都會(huì)往zookeeper進(jìn)行注冊(cè)，目的就是選舉出一個(gè)controller
3. 選舉過(guò)程非常簡(jiǎn)單粗暴，就是一個(gè)誰(shuí)先誰(shuí)當(dāng)?shù)倪^(guò)程，不涉及什么算法問(wèn)題。
4. 成為controller之后，它會(huì)監(jiān)聽(tīng)zookeeper里面的多個(gè)目錄.
5. 注冊(cè)時(shí)各個(gè)節(jié)點(diǎn)必定會(huì)暴露自己的主機(jī)名，端口號(hào)等等的信息，此時(shí)controller就要去讀取注冊(cè)上來(lái)的從節(jié)點(diǎn)的數(shù)據(jù)(通過(guò)監(jiān)聽(tīng)機(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 控制器。

在之前的版本中，如果沒(méi)有 ZooKeeper，Kafka 將無(wú)法運(yùn)行。但管理部署兩個(gè)不同的系統(tǒng)不僅讓運(yùn)維復(fù)雜度翻倍，還讓 Kafka 變得沉重，進(jìn)而限制了 Kafka 在輕量環(huán)境下的應(yīng)用，同時(shí) ZooKeeper 的分區(qū)特性也限制了 Kafka 的承載能力。

第一次，用戶可以在沒(méi)有 ZooKeeper 的情況下運(yùn)行 Kafka。

這是一次架構(gòu)上的重大升級(jí)，讓一向“重量級(jí)”的 Kafka 從此變得簡(jiǎn)單了起來(lái)。輕量級(jí)的單進(jìn)程部署可以作為 ActiveMQ 或 RabbitMQ 等的替代方案，同時(shí)也適合于邊緣場(chǎng)景和使用輕量級(jí)硬件的場(chǎng)景。

為什么要拋棄使用了十年的 ZooKeeper?

zk的缺點(diǎn)：

• zookeeper 的一個(gè)缺點(diǎn)就是 同步數(shù)據(jù)不能太大。
• zookeeper集群中l(wèi)eader和follower同步數(shù)據(jù)的極限值是500M，這500M的數(shù)據(jù)，加載到內(nèi)存中，大約占用3個(gè)G的內(nèi)存。
• 數(shù)據(jù)過(guò)大，在每次選舉之后，需要從server同步到follower，容易造成下面2個(gè)問(wèn)題：

1. 觸發(fā)重新選舉
2. io 太久

ZooKeeper 充當(dāng) Kafka 的領(lǐng)導(dǎo)者，以更新集群中的拓?fù)涓?根據(jù) ZooKeeper 提供的通知，生產(chǎn)者和消費(fèi)者發(fā)現(xiàn)整個(gè) Kafka 集群中是否存在任何新 Broker 或 Broker 失敗。大多數(shù)的運(yùn)維操作，比如說(shuō)擴(kuò)容、分區(qū)遷移等等，都需要和 ZooKeeper 交互。

也就是說(shuō)，Kafka 代碼庫(kù)中有很大一部分是負(fù)責(zé)實(shí)現(xiàn)在集群中多個(gè) Broker 之間分配分區(qū)(即日志)、分配領(lǐng)導(dǎo)權(quán)、處理故障等分布式系統(tǒng)的功能。而早已經(jīng)過(guò)業(yè)界廣泛使用和驗(yàn)證過(guò)的 ZooKeeper 是分布式代碼工作的關(guān)鍵部分。

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

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