聊聊 Kafka： Kafka 的基礎(chǔ)架構(gòu)

一、我與快遞小哥的故事

一個(gè)很正常的一個(gè)工作日，老周正在忙著啪啪啪的敲代碼，辦公司好像安靜的只剩敲代碼的聲音。突然，我的電話鈴聲響起了，頓時(shí)打破了這種安靜。

我：喂，哪位？
快遞小哥：我是順豐快遞的，你有個(gè)包裹，請(qǐng)問(wèn)你現(xiàn)在在家嗎？
我：哦，我現(xiàn)在不在家，晚上你再幫我送過(guò)來(lái)吧。
快遞小哥：要不我?guī)湍惴旁诓锁B(niǎo)驛站吧？
我：可以可以，謝謝了。

還好有菜鳥(niǎo)驛站，不然工作日加班到很晚才回家，晚上快遞小哥又下班了，得等到周末我在家快遞小哥才能幫我送了。如果沒(méi)有菜鳥(niǎo)驛站的話，我們來(lái)看下快遞小哥與我的交互圖：

小伙伴們可能發(fā)現(xiàn)了菜鳥(niǎo)驛站的好處了，真香。

這里老周來(lái)總結(jié)幾點(diǎn)消息隊(duì)列的好處也就是使用場(chǎng)景：

• 應(yīng)用解耦
  到了什么 618、雙 11，快遞小哥要忙瘋了，他得每個(gè)電話打，然后詢問(wèn)客戶在不在家，幾點(diǎn)有時(shí)間，這樣完全依賴收貨人，那快遞小哥估計(jì)要瘋。有了菜鳥(niǎo)驛站，快遞小哥直接把快遞放在菜鳥(niǎo)驛站，然后通知收貨人過(guò)去取就好了，這就讓收貨人與快遞小哥實(shí)現(xiàn)了解耦。在軟件行業(yè)的話，即應(yīng)用解耦。

• 異步處理
  要是沒(méi)有菜鳥(niǎo)驛站，快遞小哥得在樓下等你下來(lái)拿快遞，拿完了他才能走，這叫同步處理。有了菜鳥(niǎo)驛站，快遞小哥把你的快遞放在了菜鳥(niǎo)驛站，通知你去取，然后他繼續(xù)干別的事情去了，這叫異步處理。異步處理明顯提升了快遞小哥的工作效率，在軟件中，寫(xiě)異步代碼同樣能提升代碼的執(zhí)行效率。

• 流量削鋒
  雙十一老周買了很多東西，不同的店發(fā)的快遞不一樣，有順豐、韻達(dá)、中通、申通，都在我周日上午十點(diǎn)這個(gè)時(shí)間段下去拿，搞得我下樓好頻繁這個(gè)時(shí)間段，有了菜鳥(niǎo)驛站，我可以吃中午飯?jiān)傧氯ロ槺隳孟驴爝f，這就達(dá)到了十點(diǎn)那個(gè)時(shí)間段的流量削鋒效果。

我與快遞小哥的故事是真實(shí)發(fā)生的哈，正好我有個(gè)讀者前段時(shí)間面試順豐的時(shí)候被問(wèn)到 Kafka 了，要我出 Kafka 的內(nèi)容，所以有了靈感寫(xiě)了這篇文章。

二、Kafka 介紹

Kafka 是最初由 Linkedin 公司開(kāi)發(fā)，是一個(gè) 分布式、分區(qū)的、多副本的、多生產(chǎn)者、多訂閱者，基于zookeeper 協(xié)調(diào)的分布式消息系統(tǒng)。常見(jiàn)可以用于 web/nginx 日志、訪問(wèn)日志，消息服務(wù)等。

Linkedin 于 2010 年貢獻(xiàn)給了 Apache 基金會(huì)并成為頂級(jí)開(kāi)源項(xiàng)目。

2.1 基于zookeeper 協(xié)調(diào)

這里老周要提一下，Kafka 2.8.0 版本實(shí)現(xiàn)了 Raft 分布式一致性機(jī)制，意味著可以脫離 ZooKeeper 獨(dú)立運(yùn)行了。

ZooKeeper 在 Kafka 中扮演著重要的角色，用來(lái)存儲(chǔ) Kafka 的元數(shù)據(jù)。ZooKeeper 存儲(chǔ)著 Partition 和 Broker 的元數(shù)據(jù) ，同時(shí)也負(fù)責(zé) Kafka Controller 的選舉工作。

對(duì)于 Kafka 來(lái)講，ZooKeeper 是一套外部系統(tǒng)，要想部署一套 Kafka 集群，就要同時(shí)部署、管理、監(jiān)控 ZooKeeper。ZooKeeper 有自己的配置方式、管理工具，和 Kafka 完全不一樣，所以，一起搞兩套分布式系統(tǒng)，自然就提升了復(fù)雜度，也更容易出現(xiàn)問(wèn)題。有時(shí)工作量還會(huì)加倍，例如要開(kāi)啟一些安全特性，Kafka 和 ZooKeeper 中都需要配置。除了復(fù)雜度，外部存儲(chǔ)也會(huì)降低系統(tǒng)效率。

例如：

• Kafka 集群每次啟動(dòng)的時(shí)候，Controller 必須從 ZooKeeper 加載集群的狀態(tài)信息。

• 選舉出一個(gè)新的 Controller 之后也會(huì)比較麻煩，因?yàn)樾枰虞d元數(shù)據(jù)，而此時(shí)元數(shù)據(jù)的量可能已經(jīng)非常大了，這就產(chǎn)生了效率問(wèn)題。

所以，ZooKeeper 帶來(lái)的復(fù)雜度、系統(tǒng)效率這兩個(gè)問(wèn)題已經(jīng)成為 Kafka 的痛點(diǎn)，Kafka 團(tuán)隊(duì)一直在努力去除對(duì) ZooKeeper 的依賴。Kafka 2.8.0 這個(gè)版本終于實(shí)現(xiàn)了。

使用 Raft 模式之后，元數(shù)據(jù)、配置信息都會(huì)保存在 @metadata 這個(gè) Topic 中，自動(dòng)在集群中復(fù)制。這樣 Kafka 就會(huì)簡(jiǎn)單輕巧很多。

但需要注意的是，Zookeeper-less Kafka 還屬于早期版本，并不完善，所以，現(xiàn)在不要應(yīng)用在線上產(chǎn)品環(huán)境中。

2.2 主要應(yīng)用場(chǎng)景

• 日志收集系統(tǒng)

• 消息系統(tǒng)

2.3 Kafka 主要設(shè)計(jì)目標(biāo)

• 以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力，即使對(duì)TB級(jí)以上數(shù)據(jù)也能保證常數(shù)時(shí)間的訪問(wèn)性能。

• 高吞吐率。即使在非常廉價(jià)的商用機(jī)器上也能做到單機(jī)支持每秒100K條消息的傳輸。

• 支持Kafka Server間的消息分區(qū)，及分布式消費(fèi)，同時(shí)保證每個(gè)partition傳輸。

• 同時(shí)支持離線數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理

• 支持在線水平擴(kuò)展

2.4 兩種主要的消息傳遞模式

2.4.1 點(diǎn)對(duì)點(diǎn)模式

2.4.2 發(fā)布訂閱模式

大部分的消息系統(tǒng)選用發(fā)布訂閱模式。Kafka 就是一種發(fā)布訂閱模式。

2.5 Kafka 四個(gè)核心 API

• Producer API：允許應(yīng)用程序?qū)⒂涗浟靼l(fā)布到一個(gè)或多個(gè) Kafka 主題。

• Consumer API：允許應(yīng)用程序訂閱一個(gè)或多個(gè)主題并處理為其生成的記錄流。

• Streams API：允許應(yīng)用程序充當(dāng)流處理器，使用一個(gè)或多個(gè)主題的輸入流，并生成一個(gè)或多個(gè)輸出主題的輸出流，從而有效地將輸入流轉(zhuǎn)換為輸出流。

• Connector API：允許構(gòu)建和運(yùn)行將 Kafka 主題連接到現(xiàn)有應(yīng)用程序或數(shù)據(jù)系統(tǒng)的可重用生產(chǎn)者或使用者。例如，關(guān)系數(shù)據(jù)庫(kù)的連接器可能會(huì)捕獲對(duì)表的所有更改。

三、Kafka 的優(yōu)勢(shì)

• 高吞吐量：?jiǎn)螜C(jī)每秒處理幾十上百萬(wàn)的消息量。即使存儲(chǔ)了許多的消息，它也保持穩(wěn)定的性能。

• 高性能：?jiǎn)喂?jié)點(diǎn)支持上千個(gè)客戶端，并保證零停機(jī)和零數(shù)據(jù)丟失。

• 持久化數(shù)據(jù)存儲(chǔ)：將消息持久化到磁盤。通過(guò)將數(shù)據(jù)持久化到硬盤以及防止數(shù)據(jù)丟失。（零拷貝、 順序讀，順序?qū)?、利用的?yè)緩存）

• 分布式系統(tǒng)，易于向外擴(kuò)展。所有的 Producer、Broker 和 Consumer 都會(huì)有多個(gè)，均為分布式的。
  無(wú)需停機(jī)即可擴(kuò)展機(jī)器。多個(gè) Producer、Consumer 可能是不同的應(yīng)用。

• 可靠性：Kafka 是分布式、分區(qū)、復(fù)制和容錯(cuò)的。

• 客戶端狀態(tài)維護(hù)：消息被處理的狀態(tài)是在 Consumer 端維護(hù)，而不是由 server 端維護(hù)。當(dāng)失敗時(shí)能自動(dòng)平衡。

• 支持 online 和 offline 的場(chǎng)景

• 支持多種客戶端語(yǔ)言。Kafka 支持 Java、.NET、PHP、Python 等多種語(yǔ)言。

四、Kafka 的應(yīng)用場(chǎng)景

4.1 日志收集

Kafka 可以收集各種服務(wù)的 Log，通過(guò) Kafka 以統(tǒng)一接口服務(wù)的方式開(kāi)放給各種 Consumer。

4.2 消息系統(tǒng)

解耦生產(chǎn)者和消費(fèi)者、緩存消息等。

4.3 用戶活動(dòng)跟蹤

• Kafka 經(jīng)常被用來(lái)記錄 Web 用戶或者 App 用戶的各種活動(dòng)，如瀏覽網(wǎng)頁(yè)、搜索、點(diǎn)擊等活動(dòng)。

• 這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到 Kafka 的 Topic 中，然后消費(fèi)者通過(guò)訂閱這些 Topic 來(lái)做實(shí)時(shí)的監(jiān)控分析，亦可保存到數(shù)據(jù)庫(kù)。

4.4 運(yùn)營(yíng)指標(biāo)

Kafka 也經(jīng)常用來(lái)記錄運(yùn)營(yíng)監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報(bào)警和報(bào)告。

4.5 流式處理

比如 Spark Streaming 和 Storm。

五、基礎(chǔ)架構(gòu)

5.1 Kafka 架構(gòu)圖

• Kafka 的數(shù)據(jù)單元稱為消息?？梢园严⒖闯墒菙?shù)據(jù)庫(kù)里的一個(gè)“數(shù)據(jù)行”或一條“記錄”。消息由字節(jié)數(shù)組組成。

• 消息有鍵，鍵也是一個(gè)字節(jié)數(shù)組。當(dāng)消息以一種可控的方式寫(xiě)入不同的分區(qū)時(shí)，會(huì)用到鍵。

• 為了提高效率，消息被分批寫(xiě)入 Kafka。批次就是一組消息，這些消息屬于同一個(gè)主題和分區(qū)。

• 把消息分成批次可以減少網(wǎng)絡(luò)開(kāi)銷。批次越大，單位時(shí)間內(nèi)處理的消息就越多，單個(gè)消息的傳輸時(shí)間就越長(zhǎng)。批次數(shù)據(jù)會(huì)被壓縮，這樣可以提升數(shù)據(jù)的傳輸和存儲(chǔ)能力，但是需要更多的計(jì)算處理。

5.3 模式

• 消息模式（schema）有許多可用的選項(xiàng)，以便于理解。如 JSON 和 XML，但是它們?nèi)狈?qiáng)類型處理能力。Kafka 的許多開(kāi)發(fā)者喜歡使用 Apache Avro。Avro 提供了一種緊湊的序列化格式，模式和消息體分開(kāi)。當(dāng)模式發(fā)生變化時(shí)，不需要重新生成代碼，它還支持強(qiáng)類型和模式進(jìn)化，其版本既向前兼容，也向后兼容。

• 數(shù)據(jù)格式的一致性對(duì) Kafka 很重要，因?yàn)樗讼⒆x寫(xiě)操作之間的耦合性。

5.4 主題和分區(qū)

• Kafka 的消息通過(guò)主題進(jìn)行分類。主題可比是數(shù)據(jù)庫(kù)的表或者文件系統(tǒng)里的文件夾。

  主題可以被分為若干分區(qū)，一個(gè)主題通過(guò)分區(qū)分布于 Kafka 集群中，提供了橫向擴(kuò)展的能力。
  

  

5.5 生產(chǎn)者和消費(fèi)者

• 生產(chǎn)者創(chuàng)建消息。消費(fèi)者消費(fèi)消息。

• 一個(gè)消息被發(fā)布到一個(gè)特定的主題上。

• 生產(chǎn)者在默認(rèn)情況下把消息均衡地分布到主題的所有分區(qū)上：

• 直接指定消息的分區(qū)

• 根據(jù)消息的 key 散列取模得出分區(qū)

• 輪詢指定分區(qū)

• 消費(fèi)者通過(guò)偏移量來(lái)區(qū)分已經(jīng)讀過(guò)的消息，從而消費(fèi)消息。

• 消費(fèi)者是消費(fèi)組的一部分。消費(fèi)組保證每個(gè)分區(qū)只能被一個(gè)消費(fèi)者使用，避免重復(fù)消費(fèi)。

• 一個(gè)獨(dú)立的 Kafka 服務(wù)器稱為 broker。

• broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量，并提交消息到磁盤保存。

• broker 為消費(fèi)者提供服務(wù)，對(duì)讀取分區(qū)的請(qǐng)求做出響應(yīng)，返回已經(jīng)提交到磁盤上的消息。

• 單個(gè) broker 可以輕松處理數(shù)千個(gè)分區(qū)以及每秒百萬(wàn)級(jí)的消息量。

控制器負(fù)責(zé)管理工作：

• 將分區(qū)分配給 broker

• 監(jiān)控 broker

集群中一個(gè)分區(qū)屬于一個(gè) broker，該 broker 稱為分區(qū)首領(lǐng)。
一個(gè)分區(qū)可以分配給多個(gè) broker，此時(shí)會(huì)發(fā)生分區(qū)復(fù)制。
分區(qū)的復(fù)制提供了消息冗余， 高可用 。副本分區(qū)不負(fù)責(zé)處理消息的讀寫(xiě)。

六、核心概念

6.1 Producer

生產(chǎn)者創(chuàng)建消息。

該角色將消息發(fā)布到 Kafka 的 topic 中。broker 接收到生產(chǎn)者發(fā)送的消息后，broker 將該消息追加到當(dāng)前用于追加數(shù)據(jù)的 segment 文件中。

一般情況下，一個(gè)消息會(huì)被發(fā)布到一個(gè)特定的主題上。

• 默認(rèn)情況下通過(guò)輪詢把消息均衡地分布到主題的所有分區(qū)上。

• 在某些情況下，生產(chǎn)者會(huì)把消息直接寫(xiě)到指定的分區(qū)。這通常是通過(guò)消息鍵和分區(qū)器來(lái)實(shí)現(xiàn)的，分區(qū)器為鍵生成一個(gè)散列值，并將其映射到指定的分區(qū)上。這樣可以保證包含同一個(gè)鍵的消息會(huì)被寫(xiě)到同一個(gè)分區(qū)上。

• 生產(chǎn)者也可以使用自定義的分區(qū)器，根據(jù)不同的業(yè)務(wù)規(guī)則將消息映射到分區(qū)。

6.2 Consumer

消費(fèi)者讀取消息。

• 消費(fèi)者訂閱一個(gè)或多個(gè)主題，并按照消息生成的順序讀取它們。

• 消費(fèi)者通過(guò)檢查消息的偏移量來(lái)區(qū)分已經(jīng)讀取過(guò)的消息。偏移量是另一種元數(shù)據(jù)，它是一個(gè)不斷遞增的整數(shù)值，在創(chuàng)建消息時(shí)，Kafka 會(huì)把它添加到消息里。在給定的分區(qū)里，每個(gè)消息的偏移量都是唯一的。消費(fèi)者把每個(gè)分區(qū)最后讀取的消息偏移量保存在 Zookeeper 或 Kafka上 ，如果消費(fèi)者關(guān)閉或重啟，它的讀取狀態(tài)不會(huì)丟失。

• 消費(fèi)者是消費(fèi)組的一部分。群組保證每個(gè)分區(qū)只能被一個(gè)消費(fèi)者使用。

• 如果一個(gè)消費(fèi)者失效，消費(fèi)組里的其他消費(fèi)者可以接管失效消費(fèi)者的工作，再平衡，分區(qū)重新分配。

一個(gè)獨(dú)立的 Kafka 服務(wù)器被稱為 broker。

broker 為消費(fèi)者提供服務(wù)，對(duì)讀取分區(qū)的請(qǐng)求作出響應(yīng)，返回已經(jīng)提交到磁盤上的消息。

• 如果某 topic 有 N 個(gè) partition，集群有 N 個(gè) broker，那么每個(gè) broker 存儲(chǔ)該 topic 的一個(gè) partition。

• 如果某 topic 有 N 個(gè) partition，集群有 (N+M) 個(gè) broker，那么其中有 N 個(gè) broker 存儲(chǔ)該 topic 的一個(gè)partition，剩下的 M 個(gè) broker 不存儲(chǔ)該 topic 的 partition 數(shù)據(jù)。

• 如果某 topic 有 N 個(gè) partition，集群中 broker 數(shù)目少于 N 個(gè)，那么一個(gè) broker 存儲(chǔ)該 topic 的一個(gè)或多個(gè) partition。在實(shí)際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導(dǎo)致 Kafka 集群數(shù)據(jù)不均衡。

broker 是集群的組成部分。每個(gè)集群都有一個(gè) broker  同時(shí)充當(dāng)了集群控制器的角色（自動(dòng)從集群的活躍成員中選舉出來(lái)）。

控制器負(fù)責(zé)管理工作，包括將分區(qū)分配給 broker 和監(jiān)控 broker。

在集群中，一個(gè)分區(qū)從屬于一個(gè) broker，該 broker 被稱為分區(qū)的首領(lǐng)。

每條發(fā)布到 Kafka 集群的消息都有一個(gè)類別，這個(gè)類別被稱為 Topic。

物理上不同 Topic 的消息分開(kāi)存儲(chǔ)。

主題就好比數(shù)據(jù)庫(kù)的表，尤其是分庫(kù)分表之后的邏輯表。

6.5 Partition

• 主題可以被分為若干個(gè)分區(qū)，一個(gè)分區(qū)就是一個(gè)提交日志。

• 消息以追加的方式寫(xiě)入分區(qū)，然后以先入先出的順序讀取。

• 無(wú)法在整個(gè)主題范圍內(nèi)保證消息的順序，但可以保證消息在單個(gè)分區(qū)內(nèi)的順序。

• Kafka 通過(guò)分區(qū)來(lái)實(shí)現(xiàn)數(shù)據(jù)冗余和伸縮性。

• 在需要嚴(yán)格保證消息的消費(fèi)順序的場(chǎng)景下，需要將 partition 數(shù)目設(shè)為1。

6.6 Replicas

Kafka 使用主題來(lái)組織數(shù)據(jù)，每個(gè)主題被分為若干個(gè)分區(qū)，每個(gè)分區(qū)有多個(gè)副本。那些副本被保存在broker 上，每個(gè)broker 可以保存成百上千個(gè)屬于不同主題和分區(qū)的副本。

副本有以下兩種類型：

• 首領(lǐng)副本
      每個(gè)分區(qū)都有一個(gè)首領(lǐng)副本。為了保證一致性，所有生產(chǎn)者請(qǐng)求和消費(fèi)者請(qǐng)求都會(huì)經(jīng)過(guò)這個(gè)副本。

• 跟隨者副本
      首領(lǐng)以外的副本都是跟隨者副本。跟隨者副本不處理來(lái)自客戶端的請(qǐng)求，它們唯一的任務(wù)就是從首領(lǐng)那里復(fù)制消息，保持與首領(lǐng)一致的狀態(tài)。如果首領(lǐng)發(fā)生崩潰，其中的一個(gè)跟隨者會(huì)被提升為新首領(lǐng)。

6.7 Offset

6.7.1 生產(chǎn)者 Offset

消息寫(xiě)入的時(shí)候，每一個(gè)分區(qū)都有一個(gè) offset，這個(gè) offset 就是生產(chǎn)者的 offset，同時(shí)也是這個(gè)分區(qū)的最新最大的 offset。

有些時(shí)候沒(méi)有指定某一個(gè)分區(qū)的 offset，這個(gè)工作 kafka 幫我們完成。

6.7.2 消費(fèi)者 Offset

這是某一個(gè)分區(qū)的 offset 情況，生產(chǎn)者寫(xiě)入的 offset 是最新最大的值是12，而當(dāng) Consumer A 進(jìn)行消費(fèi)時(shí)，從 0 開(kāi)始消費(fèi)，一直消費(fèi)到了 9，消費(fèi)者的 offset 就記錄在 9，Consumer B 就紀(jì)錄在了 11。等下一次他們?cè)賮?lái)消費(fèi)時(shí)，他們可以選擇接著上一次的位置消費(fèi)，當(dāng)然也可以選擇從頭消費(fèi)，或者跳到最近的記錄并從“現(xiàn)在”開(kāi)始消費(fèi)。

6.8、副本

Kafka 通過(guò)副本保證高可用。副本分為首領(lǐng)副本(Leader)和跟隨者副本(Follower)。

跟隨者副本包括同步副本和不同步副本，在發(fā)生首領(lǐng)副本切換的時(shí)候，只有同步副本可以切換為首領(lǐng)副本。

6.8.1 AR

分區(qū)中的所有副本統(tǒng)稱為AR（Assigned Repllicas）

AR=ISR+OSR

6.8.2 ISR

所有與leader副本保持一定程度同步的副本（包括Leader）組成ISR（In-Sync Replicas），ISR 集合是 AR 集合中的一個(gè)子集。消息會(huì)先發(fā)送到 leader 副本，然后 follower 副本才能從 leader 副本中拉取消息進(jìn)行同步，同步期間內(nèi) follower 副本相對(duì)于 leader 副本而言會(huì)有一定程度的滯后。前面所說(shuō)的“一定程度”是指可以忍受的滯后范圍，這個(gè)范圍可以通過(guò)參數(shù)進(jìn)行配置。

6.8.3 OSR

與leader副本同步滯后過(guò)多的副本（不包括leader）副本，組成OSR(Out-Sync Relipcas)。在正常情況下，所有的 follower 副本都應(yīng)該與 leader 副本保持一定程度的同步，即 AR=ISR,OSR 集合為空。

6.8.4 HW

HW 是High Watermak的縮寫(xiě)， 俗稱高水位，它表示了一個(gè)特定消息的偏移量（offset），消費(fèi)者只能拉取到這個(gè)offset之前的消息。

6.8.5 LEO

LEO 是Log End Offset的縮寫(xiě)，它表示了當(dāng)前日志文件中下一條待寫(xiě)入消息的 offset。