共計 4588 個字符，預(yù)計需要花費(fèi) 12 分鐘才能閱讀完成。

本篇文章為大家展示了怎么解析分布式消息系統(tǒng) Kafka，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

Kafka 是分布式發(fā)布 - 訂閱消息系統(tǒng)。它最初由 LinkedIn 公司開發(fā)，之后成為 Apache 項目的一部分。Kafka 是一個分布式的，可劃分的，冗余備份的持久性的日志服務(wù)。它主要用于處理活躍的流式數(shù)據(jù)。

在大數(shù)據(jù)系統(tǒng)中，常常會碰到一個問題，整個大數(shù)據(jù)是由各個子系統(tǒng)組成，數(shù)據(jù)需要在各個子系統(tǒng)中高性能，低延遲的不停流轉(zhuǎn)。傳統(tǒng)的企業(yè)消息系統(tǒng)并不是非常適合大規(guī)模的數(shù)據(jù)處理。為了已在同時搞定在線應(yīng)用（消息）和離線應(yīng)用（數(shù)據(jù)文件，日志）Kafka 就出現(xiàn)了。Kafka 可以起到兩個作用：

降低系統(tǒng)組網(wǎng)復(fù)雜度。

降低編程復(fù)雜度，各個子系統(tǒng)不在是相互協(xié)商接口，各個子系統(tǒng)類似插口插在插座上，Kafka 承擔(dān)高速數(shù)據(jù)總線的作用。

1、Kafka 主要特點(diǎn)：

同時為發(fā)布和訂閱提供高吞吐量。據(jù)了解，Kafka 每秒可以生產(chǎn)約 25 萬消息（50 MB），每秒處理 55 萬消息（110 MB）。

可進(jìn)行持久化操作。將消息持久化到磁盤，因此可用于批量消費(fèi)，例如 ETL，以及實(shí)時應(yīng)用程序。通過將數(shù)據(jù)持久化到硬盤以及 replication 防止數(shù)據(jù)丟失。

分布式系統(tǒng)，易于向外擴(kuò)展。所有的 producer、broker 和 consumer 都會有多個，均為分布式的。無需停機(jī)即可擴(kuò)展機(jī)器。

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

支持 online 和 offline 的場景。

2、Kafka 的架構(gòu)：

Kafka 的整體架構(gòu)非常簡單，是顯式分布式架構(gòu)，producer、broker（kafka）和 consumer 都可以有多個。Producer，consumer 實(shí)現(xiàn) Kafka 注冊的接口，數(shù)據(jù)從 producer 發(fā)送到 broker，broker 承擔(dān)一個中間緩存和分發(fā)的作用。broker 分發(fā)注冊到系統(tǒng)中的 consumer。broker 的作用類似于緩存，即活躍的數(shù)據(jù)和離線處理系統(tǒng)之間的緩存。客戶端和服務(wù)器端的通信，是基于簡單，高性能，且與編程語言無關(guān)的 TCP 協(xié)議。

3、幾個基本概念：

Topic：特指 Kafka 處理的消息源（feeds of messages）的不同分類。

Partition：Topic 物理上的分組，一個 topic 可以分為多個 partition，每個 partition 是一個有序的隊列。partition 中的每條消息都會被分配一個有序的 id（offset）。

Message：消息，是通信的基本單位，每個 producer 可以向一個 topic（主題）發(fā)布一些消息。

Producers：消息和數(shù)據(jù)生產(chǎn)者，向 Kafka 的一個 topic 發(fā)布消息的過程叫做 producers。

Consumers：消息和數(shù)據(jù)消費(fèi)者，訂閱 topics 并處理其發(fā)布的消息的過程叫做 consumers。

Broker：緩存代理，Kafa 集群中的一臺或多臺服務(wù)器統(tǒng)稱為 broker。

4、消息發(fā)送的流程：

Producer 根據(jù)指定的 partition 方法（round-robin、hash 等），將消息發(fā)布到指定 topic 的 partition 里面

kafka 集群接收到 Producer 發(fā)過來的消息后，將其持久化到硬盤，并保留消息指定時長（可配置），而不關(guān)注消息是否被消費(fèi)。

Consumer 從 kafka 集群 pull 數(shù)據(jù)，并控制獲取消息的 offset

5、Kafka 的設(shè)計：5.1 吞吐量

高吞吐是 kafka 需要實(shí)現(xiàn)的核心目標(biāo)之一，為此 kafka 做了以下一些設(shè)計：

數(shù)據(jù)磁盤持久化：消息不在內(nèi)存中 cache，直接寫入到磁盤，充分利用磁盤的順序讀寫性能

zero-copy：減少 IO 操作步驟

數(shù)據(jù)批量發(fā)送

數(shù)據(jù)壓縮

Topic 劃分為多個 partition，提高 parallelism

5.2 負(fù)載均衡

producer 根據(jù)用戶指定的算法，將消息發(fā)送到指定的 partition

存在多個 partiiton，每個 partition 有自己的 replica，每個 replica 分布在不同的 Broker 節(jié)點(diǎn)上

多個 partition 需要選取出 lead partition，lead partition 負(fù)責(zé)讀寫，并由 zookeeper 負(fù)責(zé) fail over

通過 zookeeper 管理 broker 與 consumer 的動態(tài)加入與離開

5.3 拉取系統(tǒng)

由于 kafka broker 會持久化數(shù)據(jù)，broker 沒有內(nèi)存壓力，因此，consumer 非常適合采取 pull 的方式消費(fèi)數(shù)據(jù)，具有以下幾點(diǎn)好處：

簡化 kafka 設(shè)計

consumer 根據(jù)消費(fèi)能力自主控制消息拉取速度

consumer 根據(jù)自身情況自主選擇消費(fèi)模式，例如批量，重復(fù)消費(fèi)，從尾端開始消費(fèi)等

5.4 可擴(kuò)展性

當(dāng)需要增加 broker 結(jié)點(diǎn)時，新增的 broker 會向 zookeeper 注冊，而 producer 及 consumer 會根據(jù)注冊在 zookeeper 上的 watcher 感知這些變化，并及時作出調(diào)整。

5.5 消息刪除策略

kafka 和 JMS 實(shí)現(xiàn) (activeMQ) 不同的是: 即使消息被消費(fèi), 消息仍然不會被立即刪除. 日志文件將會根據(jù) broker 中的配置要求, 保留一定的時間之后刪除; 比如 log 文件保留 2 天, 那么兩天后, 文件會被清除, 無論其中的消息是否被消費(fèi).kafka 通過這種簡單的手段, 來釋放磁盤空間. 此外,kafka 的性能并不會因?yàn)槿罩疚募奶喽拖? 所以即使保留較多的 log 文件, 也不不會有問題.

kafka 中 consumer 負(fù)責(zé)維護(hù)消息的消費(fèi)記錄, 而 broker 則不關(guān)心這些, 這種設(shè)計不僅提高了 consumer 端的靈活性, 也適度的減輕了 broker 端設(shè)計的復(fù)雜度; 這是和眾多 JMS prodiver 的區(qū)別. 此外,kafka 中消息 ACK 的設(shè)計也和 JMS 有很大不同,kafka 中的消息時批量 (通常以消息的條數(shù)或者 chunk 的尺寸為單位) 發(fā)送給 consumer, 當(dāng)消息消費(fèi)成功后, 向 zookeeper 提交消息的 offset, 而不會向 broker 交付 ACK. 或許你已經(jīng)意識到, 這種 寬松 的設(shè)計, 將會有 丟失 消息 / 消息重發(fā) 的危險.

6、Kafka 的應(yīng)用場景：6.1 消息隊列

比起大多數(shù)的消息系統(tǒng)來說，Kafka 有更好的吞吐量，內(nèi)置的分區(qū)，冗余及容錯性，這讓 Kafka 成為了一個很好的大規(guī)模消息處理應(yīng)用的解決方案。消息系統(tǒng)一般吞吐量相對較低，但是需要更小的端到端延時，并嘗嘗依賴于 Kafka 提供的強(qiáng)大的持久性保障。在這個領(lǐng)域，Kafka 足以媲美傳統(tǒng)消息系統(tǒng)，如 ActiveMR 或 RabbitMQ。

6.2 行為跟蹤

Kafka 的另一個應(yīng)用場景是跟蹤用戶瀏覽頁面、搜索及其他行為，以發(fā)布 - 訂閱的模式實(shí)時記錄到對應(yīng)的 topic 里。那么這些結(jié)果被訂閱者拿到后，就可以做進(jìn)一步的實(shí)時處理，或?qū)崟r監(jiān)控，或放到 hadoop/ 離線數(shù)據(jù)倉庫里處理。

6.3 元信息監(jiān)控

作為操作記錄的監(jiān)控模塊來使用，即匯集記錄一些操作信息，可以理解為運(yùn)維性質(zhì)的數(shù)據(jù)監(jiān)控吧。

6.4 日志收集

日志收集方面，其實(shí)開源產(chǎn)品有很多，包括 Scribe、Apache Flume。很多人使用 Kafka 代替日志聚合（log aggregation）。日志聚合一般來說是從服務(wù)器上收集日志文件，然后放到一個集中的位置（文件服務(wù)器或 HDFS）進(jìn)行處理。然而 Kafka 忽略掉文件的細(xì)節(jié)，將其更清晰地抽象成一個個日志或事件的消息流。這就讓 Kafka 處理過程延遲更低，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的系統(tǒng)比如 Scribe 或者 Flume 來說，Kafka 提供同樣高效的性能和因?yàn)閺?fù)制導(dǎo)致的更高的耐用性保證，以及更低的端到端延遲。

6.5 流處理

這個場景可能比較多，也很好理解。保存收集流數(shù)據(jù)，以提供之后對接的 Storm 或其他流式計算框架進(jìn)行處理。很多用戶會將那些從原始 topic 來的數(shù)據(jù)進(jìn)行階段性處理，匯總，擴(kuò)充或者以其他的方式轉(zhuǎn)換到新的 topic 下再繼續(xù)后面的處理。例如一個文章推薦的處理流程，可能是先從 RSS 數(shù)據(jù)源中抓取文章的內(nèi)容，然后將其丟入一個叫做“文章”的 topic 中；后續(xù)操作可能是需要對這個內(nèi)容進(jìn)行清理，比如回復(fù)正常數(shù)據(jù)或者刪除重復(fù)數(shù)據(jù)，最后再將內(nèi)容匹配的結(jié)果返還給用戶。這就在一個獨(dú)立的 topic 之外，產(chǎn)生了一系列的實(shí)時數(shù)據(jù)處理的流程。Strom 和 Samza 是非常著名的實(shí)現(xiàn)這種類型數(shù)據(jù)轉(zhuǎn)換的框架。

6.6 事件源

事件源是一種應(yīng)用程序設(shè)計的方式，該方式的狀態(tài)轉(zhuǎn)移被記錄為按時間順序排序的記錄序列。Kafka 可以存儲大量的日志數(shù)據(jù)，這使得它成為一個對這種方式的應(yīng)用來說絕佳的后臺。比如動態(tài)匯總（News feed）。

6.7 持久性日志（commit log）

Kafka 可以為一種外部的持久性日志的分布式系統(tǒng)提供服務(wù)。這種日志可以在節(jié)點(diǎn)間備份數(shù)據(jù)，并為故障節(jié)點(diǎn)數(shù)據(jù)回復(fù)提供一種重新同步的機(jī)制。Kafka 中日志壓縮功能為這種用法提供了條件。在這種用法中，Kafka 類似于 Apache BookKeeper 項目。

7、Kafka 的設(shè)計要點(diǎn)：7.1 直接使用 linux 文件系統(tǒng)的 cache，來高效緩存數(shù)據(jù)。7.2 采用 linux Zero-Copy 提高發(fā)送性能。

傳統(tǒng)的數(shù)據(jù)發(fā)送需要發(fā)送 4 次上下文切換，采用 sendfile 系統(tǒng)調(diào)用之后，數(shù)據(jù)直接在內(nèi)核態(tài)交換，系統(tǒng)上下文切換減少為 2 次。根據(jù)測試結(jié)果，可以提高 60% 的數(shù)據(jù)發(fā)送性能。Zero-Copy 詳細(xì)的技術(shù)細(xì)節(jié)可以參考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

7.3 數(shù)據(jù)在磁盤上存取代價為 O(1)。

kafka 以 topic 來進(jìn)行消息管理，每個 topic 包含多個 part（ition），每個 part 對應(yīng)一個邏輯 log，有多個 segment 組成。每個 segment 中存儲多條消息（見下圖），消息 id 由其邏輯位置決定，即從消息 id 可直接定位到消息的存儲位置，避免 id 到位置的額外映射。每個 part 在內(nèi)存中對應(yīng)一個 index，記錄每個 segment 中的第一條消息偏移。發(fā)布者發(fā)到某個 topic 的消息會被均勻的分布到多個 part 上（隨機(jī)或根據(jù)用戶指定的回調(diào)函數(shù)進(jìn)行分布），broker 收到發(fā)布消息往對應(yīng) part 的最后一個 segment 上添加該消息，當(dāng)某個 segment 上的消息條數(shù)達(dá)到配置值或消息發(fā)布時間超過閾值時，segment 上的消息會被 flush 到磁盤，只有 flush 到磁盤上的消息訂閱者才能訂閱到，segment 達(dá)到一定的大小后將不會再往該 segment 寫數(shù)據(jù)，broker 會創(chuàng)建新的 segment。

7.4 顯式分布式。

即所有的 producer、broker 和 consumer 都會有多個，均為分布式的。Producer 和 broker 之間沒有負(fù)載均衡機(jī)制。broker 和 consumer 之間利用 zookeeper 進(jìn)行負(fù)載均衡。所有 broker 和 consumer 都會在 zookeeper 中進(jìn)行注冊，且 zookeeper 會保存他們的一些元數(shù)據(jù)信息。如果某個 broker 和 consumer 發(fā)生了變化，所有其他的 broker 和 consumer 都會得到通知。

上述內(nèi)容就是怎么解析分布式消息系統(tǒng) Kafka，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。