Kafka的四個(gè)基礎(chǔ)概念學(xué)習(xí)

Kafka 創(chuàng)建背景

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

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

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

Kafka 簡(jiǎn)介

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

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

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

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

同時(shí)支持離線(xiàn)數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理。

Scale out：支持在線(xiàn)水平擴(kuò)展。

Kafka 基礎(chǔ)概念

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

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

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

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

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

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

概念三：Broker 和集群（Cluster）

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

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

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

概念四：多集群

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

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

基于安全的隔離；

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

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

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