Kafka 創(chuàng)建背景

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

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

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

Kafka 簡介

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

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

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

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

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

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

Kafka 基礎(chǔ)概念

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

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

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

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

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

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

概念三：Broker 和集群（Cluster）

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

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

Kafka 的一個(gè)關(guān)鍵性質(zhì)是日志保留（retention），我們可以配置主題的消息保留策略，譬如只保留一段時(shí)間的日志或者只保留特定大小的日志。當(dāng)超過這些限制時(shí)，老的消息會被刪除。我們也可以針對某個(gè)主題單獨(dú)設(shè)置消息過期策略，這樣對于不同應(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è)例子，假如用戶修改了個(gè)人資料，那么后續(xù)的請求無論被哪個(gè)數(shù)據(jù)中心處理，這個(gè)更新需要反映出來。又或者，多個(gè)數(shù)據(jù)中心的數(shù)據(jù)需要匯總到一個(gè)總控中心來做數(shù)據(jù)分析。

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