一 Kafka 概述
1.1 Kafka 是什么
在流式計(jì)算中，Kafka 一般用來(lái)緩存數(shù)據(jù)，Storm 通過(guò)消費(fèi) Kafka 的數(shù)據(jù)進(jìn)行計(jì)算。
1）Apache Kafka 是一個(gè)開(kāi)源消息系統(tǒng)（微信公眾號(hào)、QQ、微信等群），由 Scala 寫(xiě)成。
是由 Apache 軟件基金會(huì)開(kāi)發(fā)的一個(gè)開(kāi)源消息系統(tǒng)項(xiàng)目。
2）Kafka 最初是由 LinkedIn 公司開(kāi)發(fā)，并于 2011 年初開(kāi)源。2012 年 10 月從 Apache
Incubator 畢業(yè)。該項(xiàng)目的目標(biāo)是為處理實(shí)時(shí)數(shù)據(jù)提供一個(gè)統(tǒng)一、高通量、低延時(shí)的平臺(tái)。
3）Kafka 是一個(gè)分布式消息隊(duì)列。Kafka 對(duì)消息保存時(shí)根據(jù) Topic 進(jìn)行歸類(lèi)，發(fā)送消息
者稱(chēng)為 Producer，消息接受者稱(chēng)為 Consumer，此外 kafka 集群有多個(gè) kafka 實(shí)例組成，每個(gè)
實(shí)例(server)成為 broker。Redis 分布式界內(nèi)的小鋼炮!!!!
4）無(wú)論是 kafka 集群，還是 producer 和 consumer 都依賴(lài)于 zookeeper 集群保存一些
meta 信息，來(lái)保證系統(tǒng)可用性。
1.2 消息隊(duì)列內(nèi)部實(shí)現(xiàn)原理

（1）點(diǎn)對(duì)點(diǎn)模式（一對(duì)一，消費(fèi)者主動(dòng)拉取數(shù)據(jù)，消息收到后消息清除）

點(diǎn)對(duì)點(diǎn)模型通常是一個(gè)基于拉取或者輪詢的消息傳送模型，這種模型從隊(duì)列中請(qǐng)求信
息，而不是將消息推送到客戶端。這個(gè)模型的特點(diǎn)是發(fā)送到隊(duì)列的消息被一個(gè)且只有一個(gè)接
收者接收處理，即使有多個(gè)消息監(jiān)聽(tīng)者也是如此。
（2）發(fā)布/訂閱模式（一對(duì)多，數(shù)據(jù)生產(chǎn)后，推送給所有訂閱者）
發(fā)布訂閱模型則是一個(gè)基于推送的消息傳送模型。發(fā)布訂閱模型可以有多種不同的訂閱
者，臨時(shí)訂閱者只在主動(dòng)監(jiān)聽(tīng)主題時(shí)才接收消息，而持久訂閱者則監(jiān)聽(tīng)主題的所有消息，即
使當(dāng)前訂閱者不可用，處于離線狀態(tài)。

為什么需要消息隊(duì)列

1）解耦：
允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過(guò)程，只要確保它們遵守同樣的接口約束。
2）冗余：
消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過(guò)這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)
險(xiǎn)。許多消息隊(duì)列所采用的"插入-獲取-刪除"范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需
要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你
使用完畢。
3）擴(kuò)展性：
因?yàn)橄㈥?duì)列解耦了你的處理過(guò)程，所以增大消息入隊(duì)和處理的頻率是很容易的，只要
另外增加處理過(guò)程即可。
4）靈活性 & 峰值處理能力：
在訪問(wèn)量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見(jiàn)。
如果為以能處理這類(lèi)峰值訪問(wèn)為標(biāo)準(zhǔn)來(lái)投入資源隨時(shí)待命無(wú)疑是巨大的浪費(fèi)。使用消息隊(duì)列
能夠使關(guān)鍵組件頂住突發(fā)的訪問(wèn)壓力，而不會(huì)因?yàn)橥话l(fā)的超負(fù)荷的請(qǐng)求而完全崩潰。
5）可恢復(fù)性：
系統(tǒng)的一部分組件失效時(shí)，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所
以即使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。
6）順序保證：
在大多使用場(chǎng)景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來(lái)就是排序的，并且
能保證數(shù)據(jù)會(huì)按照特定的順序來(lái)處理。（Kafka 保證一個(gè) Partition 內(nèi)的消息的有序性）
7）緩沖：

有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過(guò)系統(tǒng)的速度，解決生產(chǎn)消息和消費(fèi)消息的處理速度不一致
的情況。
8）異步通信：
很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶
把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要
的時(shí)候再去處理它們。
1.4 Kafka 架構(gòu)

1）Producer ：消息生產(chǎn)者，就是向 kafka broker 發(fā)消息的客戶端。
2）Consumer ：消息消費(fèi)者，向 kafka broker 取消息的客戶端
3）Topic ：可以理解為一個(gè)隊(duì)列。
4）Consumer Group （CG）：這是kafka用來(lái)實(shí)現(xiàn)一個(gè)topic消息的廣播（發(fā)給所有的consumer）
和單播（發(fā)給任意一個(gè) consumer）的手段。一個(gè) topic 可以有多個(gè) CG。topic 的消息會(huì)復(fù)制-
給 consumer。如果需要實(shí)現(xiàn)廣播，只要每個(gè) consumer 有一個(gè)獨(dú)立的 CG 就可以了。要實(shí)現(xiàn)
單播只要所有的 consumer 在同一個(gè) CG。用 CG 還可以將 consumer 進(jìn)行自由的分組而不需
要多次發(fā)送消息到不同的 topic。
5）Broker ：一臺(tái) kafka 服務(wù)器就是一個(gè) broker。一個(gè)集群由多個(gè) broker 組成。一個(gè) broker
可以容納多個(gè) topic。
6）Partition：為了實(shí)現(xiàn)擴(kuò)展性，一個(gè)非常大的 topic 可以分布到多個(gè) broker（即服務(wù)器）上，
一個(gè) topic 可以分為多個(gè) partition，每個(gè) partition 是一個(gè)有序的隊(duì)列。partition 中的每條消息

都會(huì)被分配一個(gè)有序的 id（offset）。kafka 只保證按一個(gè) partition 中的順序?qū)⑾l(fā)給
consumer，不保證一個(gè) topic 的整體（多個(gè) partition 間）的順序。
7）Offset：kafka 的存儲(chǔ)文件都是按照 offset.kafka 來(lái)命名，用 offset 做名字的好處是方便查
找。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可。當(dāng)然 the first offset 就
是 00000000000.kafka
1.5 分布式模型
Kafka 每個(gè)主題的多個(gè)分區(qū)日志分布式地存儲(chǔ)在 Kafka 集群上，同時(shí)為了故障容錯(cuò)，每
個(gè)分區(qū)都會(huì)以副本的方式復(fù)制到多個(gè)消息代理節(jié)點(diǎn)上。其中一個(gè)節(jié)點(diǎn)會(huì)作為主副本
（Leader），其他節(jié)點(diǎn)作為備份副本（Follower，也叫作從副本）。主副本會(huì)負(fù)責(zé)所有的客
戶端讀寫(xiě)操作，備份副本僅僅從主副本同步數(shù)據(jù)。當(dāng)主副本出現(xiàn)故障時(shí)，備份副本中的一個(gè)
副本會(huì)被選擇為新的主副本。因?yàn)槊總€(gè)分區(qū)的副本中只有主副本接受讀寫(xiě)，所以每個(gè)服務(wù)器
端都會(huì)作為某些分區(qū)的主副本，以及另外一些分區(qū)的備份副本，這樣 Kafka 集群的所有服務(wù)
端整體上對(duì)客戶端是負(fù)載均衡的。
Kafka 的生產(chǎn)者和消費(fèi)者相對(duì)于服務(wù)器端而言都是客戶端。
Kafka 生產(chǎn)者客戶端發(fā)布消息到服務(wù)端的指定主題，會(huì)指定消息所屬的分區(qū)。生產(chǎn)者發(fā)
布消息時(shí)根據(jù)消息是否有鍵，采用不同的分區(qū)策略。消息沒(méi)有鍵時(shí)，通過(guò)輪詢方式進(jìn)行客戶
端負(fù)載均衡；消息有鍵時(shí)，根據(jù)分區(qū)語(yǔ)義（例如 hash）確保相同鍵的消息總是發(fā)送到同一
分區(qū)。
Kafka 的消費(fèi)者通過(guò)訂閱主題來(lái)消費(fèi)消息，并且每個(gè)消費(fèi)者都會(huì)設(shè)置一個(gè)消費(fèi)組名稱(chēng)。
因?yàn)樯a(chǎn)者發(fā)布到主題的每一條消息都只會(huì)發(fā)送給消費(fèi)者組的一個(gè)消費(fèi)者。所以，如果要實(shí)
現(xiàn)傳統(tǒng)消息系統(tǒng)的“隊(duì)列”模型，可以讓每個(gè)消費(fèi)者都擁有相同的消費(fèi)組名稱(chēng)，這樣消息就
會(huì)負(fù)責(zé)均衡到所有的消費(fèi)者；如果要實(shí)現(xiàn)“發(fā)布-訂閱”模型，則每個(gè)消費(fèi)者的消費(fèi)者組名
稱(chēng)都不相同，這樣每條消息就會(huì)廣播給所有的消費(fèi)者。
分區(qū)是消費(fèi)者現(xiàn)場(chǎng)模型的最小并行單位。如下圖（圖 1）所示，生產(chǎn)者發(fā)布消息到一臺(tái)
服務(wù)器的 3 個(gè)分區(qū)時(shí)，只有一個(gè)消費(fèi)者消費(fèi)所有的 3 個(gè)分區(qū)。在下圖（圖 2）中，3 個(gè)分區(qū)
分布在 3 臺(tái)服務(wù)器上，同時(shí)有 3 個(gè)消費(fèi)者分別消費(fèi)不同的分區(qū)。假設(shè)每個(gè)服務(wù)器的吞吐量時(shí)
300MB，在下圖（圖 1）中分?jǐn)偟矫總€(gè)分區(qū)只有 100MB，而在下圖（圖 2）中，集群整體的
吞吐量有 900MB。可以看到，增加服務(wù)器節(jié)點(diǎn)會(huì)提升集群的性能，增加消費(fèi)者數(shù)量會(huì)提升
處理性能。
同一個(gè)消費(fèi)組下多個(gè)消費(fèi)者互相協(xié)調(diào)消費(fèi)工作，Kafka 會(huì)將所有的分區(qū)平均地分配給所
有的消費(fèi)者實(shí)例，這樣每個(gè)消費(fèi)者都可以分配到數(shù)量均等的分區(qū)。Kafka 的消費(fèi)組管理協(xié)議
會(huì)動(dòng)態(tài)地維護(hù)消費(fèi)組的成員列表，當(dāng)一個(gè)新消費(fèi)者加入消費(fèi)者組，或者有消費(fèi)者離開(kāi)消費(fèi)組，
都會(huì)觸發(fā)再平衡操作。

Kafka 的消費(fèi)者消費(fèi)消息時(shí)，只保證在一個(gè)分區(qū)內(nèi)的消息的完全有序性，并不保證同一
個(gè)主題匯中多個(gè)分區(qū)的消息順序。而且，消費(fèi)者讀取一個(gè)分區(qū)消息的順序和生產(chǎn)者寫(xiě)入到這
個(gè)分區(qū)的順序是一致的。比如，生產(chǎn)者寫(xiě)入“hello”和“Kafka”兩條消息到分區(qū) P1，則消
費(fèi)者讀取到的順序也一定是“hello”和“Kafka”。如果業(yè)務(wù)上需要保證所有消息完全一致，
只能通過(guò)設(shè)置一個(gè)分區(qū)完成，但這種做法的缺點(diǎn)是最多只能有一個(gè)消費(fèi)者進(jìn)行消費(fèi)。一般來(lái)
說(shuō)，只需要保證每個(gè)分區(qū)的有序性，再對(duì)消息假設(shè)鍵來(lái)保證相同鍵的所有消息落入同一分區(qū)，
就可以滿足絕大多數(shù)的應(yīng)用。
二 Kafka 集群部署

總結(jié)

以上是生活随笔為你收集整理的kafka学习默认端口号9092的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。