學(xué)習(xí)Kafka要從哪幾個基礎(chǔ)概念入手

學(xué)習(xí)Kafka要從哪幾個基礎(chǔ)概念入手，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

Kafka 創(chuàng)建背景

Kafka 是一個消息系統(tǒng)，原本開發(fā)自 LinkedIn，用作 LinkedIn 的活動流(Activity  Stream)和運營數(shù)據(jù)處理管道(Pipeline)的基礎(chǔ)?，F(xiàn)在它已被多家不同類型的公司 作為多種類型的數(shù)據(jù)管道和消息系統(tǒng)使用。

活動流數(shù)據(jù)是幾乎所有站點在對其網(wǎng)站使用情況做報表時都要用到的數(shù)據(jù)中最常規(guī)的部分?；顒訑?shù)據(jù)包括頁面訪問量(Page  View)、被查看內(nèi)容方面的信息以及搜索情況等內(nèi)容。這種數(shù)據(jù)通常的處理方式是先把各種活動以日志的形式寫入某種文件，然后周期性地對這些文件進行統(tǒng)計分析。運營數(shù)據(jù)指的是服務(wù)器的性能數(shù)據(jù)(CPU、IO  使用率、請求時間、服務(wù)日志等等數(shù)據(jù))。運營數(shù)據(jù)的統(tǒng)計方法種類繁多。

近年來，活動和運營數(shù)據(jù)處理已經(jīng)成為了網(wǎng)站軟件產(chǎn)品特性中一個至關(guān)重要的組成部分，這就需要一套稍微更加復(fù)雜的基礎(chǔ)設(shè)施對其提供支持。

Kafka 簡介

Kafka 是一種分布式的，基于發(fā)布 / 訂閱的消息系統(tǒng)。主要設(shè)計目標(biāo)如下：

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

2. 高吞吐率。即使在非常廉價的商用機器上也能做到單機支持每秒 100K 條以上消息的傳輸。

3. 支持 Kafka Server 間的消息分區(qū)，及分布式消費，同時保證每個 Partition 內(nèi)的消息順序傳輸。

4. 同時支持離線數(shù)據(jù)處理和實時數(shù)據(jù)處理。

5. Scale out：支持在線水平擴展。

Kafka 基礎(chǔ)概念

概念一：生產(chǎn)者與消費者

對于 Kafka 來說客戶端有兩種基本類型：生產(chǎn)者(Producer)和消費者(Consumer)。除此之外，還有用來做數(shù)據(jù)集成的 Kafka  Connect API 和流式處理的 Kafka Streams  等高階客戶端，但這些高階客戶端底層仍然是生產(chǎn)者和消費者API，它們只不過是在上層做了封裝。

這很容易理解，生產(chǎn)者(也稱為發(fā)布者)創(chuàng)建消息，而消費者(也稱為訂閱者)負責(zé)消費or讀取消息。

概念二：主題(Topic)與分區(qū)(Partition)

在 Kafka  中，消息以主題(Topic)來分類，每一個主題都對應(yīng)一個「消息隊列」，這有點兒類似于數(shù)據(jù)庫中的表。但是如果我們把所有同類的消息都塞入到一個“中心”隊列中，勢必缺少可伸縮性，無論是生產(chǎn)者/消費者數(shù)目的增加，還是消息數(shù)量的增加，都可能耗盡系統(tǒng)的性能或存儲。

我們使用一個生活中的例子來說明：現(xiàn)在 A 城市生產(chǎn)的某商品需要運輸?shù)?B 城市，走的是公路，那么單通道的高速公路不論是在「A 城市商品增多」還是「現(xiàn)在 C  城市也要往 B  城市運輸東西」這樣的情況下都會出現(xiàn)「吞吐量不足」的問題。所以我們現(xiàn)在引入分區(qū)(Partition)的概念，類似“允許多修幾條道”的方式對我們的主題完成了水平擴展。

概念三：Broker 和集群(Cluster)

一個 Kafka 服務(wù)器也稱為 Broker，它接受生產(chǎn)者發(fā)送的消息并存入磁盤;Broker  同時服務(wù)消費者拉取分區(qū)消息的請求，返回目前已經(jīng)提交的消息。使用特定的機器硬件，一個 Broker  每秒可以處理成千上萬的分區(qū)和百萬量級的消息。(現(xiàn)在動不動就百萬量級..我特地去查了一把，好像確實集群的情況下吞吐量挺高的..摁..)

若干個 Broker 組成一個集群(Cluster)，其中集群內(nèi)某個 Broker 會成為集群控制器(Cluster  Controller)，它負責(zé)管理集群，包括分配分區(qū)到 Broker、監(jiān)控 Broker 故障等。在集群內(nèi)，一個分區(qū)由一個 Broker 負責(zé)，這個  Broker 也稱為這個分區(qū)的 Leader;當(dāng)然一個分區(qū)可以被復(fù)制到多個 Broker 上來實現(xiàn)冗余，這樣當(dāng)存在 Broker  故障時可以將其分區(qū)重新分配到其他 Broker 來負責(zé)。下圖是一個樣例：

Kafka  的一個關(guān)鍵性質(zhì)是日志保留(retention)，我們可以配置主題的消息保留策略，譬如只保留一段時間的日志或者只保留特定大小的日志。當(dāng)超過這些限制時，老的消息會被刪除。我們也可以針對某個主題單獨設(shè)置消息過期策略，這樣對于不同應(yīng)用可以實現(xiàn)個性化。

概念四：多集群

隨著業(yè)務(wù)發(fā)展，我們往往需要多集群，通常處于下面幾個原因：

• 基于數(shù)據(jù)的隔離;

• 基于安全的隔離;

• 多數(shù)據(jù)中心(容災(zāi))

當(dāng)構(gòu)建多個數(shù)據(jù)中心時，往往需要實現(xiàn)消息互通。舉個例子，假如用戶修改了個人資料，那么后續(xù)的請求無論被哪個數(shù)據(jù)中心處理，這個更新需要反映出來。又或者，多個數(shù)據(jù)中心的數(shù)據(jù)需要匯總到一個總控中心來做數(shù)據(jù)分析。

上面說的分區(qū)復(fù)制冗余機制只適用于同一個 Kafka 集群內(nèi)部，對于多個 Kafka 集群消息同步可以使用 Kafka 提供的 MirrorMaker  工具。本質(zhì)上來說，MirrorMaker 只是一個 Kafka  消費者和生產(chǎn)者，并使用一個隊列連接起來而已。它從一個集群中消費消息，然后往另一個集群生產(chǎn)消息。

關(guān)于學(xué)習(xí)Kafka要從哪幾個基礎(chǔ)概念入手問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。