轉(zhuǎn)自：?https://developer.ibm.com/zh/articles/os-cn-kafka/?

?

消息隊(duì)列

消息隊(duì)列技術(shù)是分布式應(yīng)用間交換信息的一種技術(shù)。消息隊(duì)列可駐留在內(nèi)存或磁盤上, 隊(duì)列存儲(chǔ)消息直到它們被應(yīng)用程序讀走。通過(guò)消息隊(duì)列，應(yīng)用程序可獨(dú)立地執(zhí)行–它們不需要知道彼此的位置、或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息。在分布式計(jì)算環(huán)境中，為了集成分布式應(yīng)用，開發(fā)者需要對(duì)異構(gòu)網(wǎng)絡(luò)環(huán)境下的分布式應(yīng)用提供有效的通信手段。為了管理需要共享的信息，對(duì)應(yīng)用提供公共的信息交換機(jī)制是重要的。常用的消息隊(duì)列技術(shù)是 Message Queue。

Message Queue 的通訊模式

點(diǎn)對(duì)點(diǎn)通訊：點(diǎn)對(duì)點(diǎn)方式是最為傳統(tǒng)和常見的通訊方式，它支持一對(duì)一、一對(duì)多、多對(duì)多、多對(duì)一等多種配置方式，支持樹狀、網(wǎng)狀等多種拓?fù)浣Y(jié)構(gòu)。

多點(diǎn)廣播：MQ 適用于不同類型的應(yīng)用。其中重要的，也是正在發(fā)展中的是”多點(diǎn)廣播”應(yīng)用，即能夠?qū)⑾l(fā)送到多個(gè)目標(biāo)站點(diǎn) (Destination List)。可以使用一條 MQ 指令將單一消息發(fā)送到多個(gè)目標(biāo)站點(diǎn)，并確保為每一站點(diǎn)可靠地提供信息。MQ 不僅提供了多點(diǎn)廣播的功能，而且還擁有智能消息分發(fā)功能，在將一條消息發(fā)送到同一系統(tǒng)上的多個(gè)用戶時(shí)，MQ 將消息的一個(gè)復(fù)制版本和該系統(tǒng)上接收者的名單發(fā)送到目標(biāo) MQ 系統(tǒng)。目標(biāo) MQ 系統(tǒng)在本地復(fù)制這些消息，并將它們發(fā)送到名單上的隊(duì)列，從而盡可能減少網(wǎng)絡(luò)的傳輸量。

發(fā)布/訂閱 (Publish/Subscribe) 模式：發(fā)布/訂閱功能使消息的分發(fā)可以突破目的隊(duì)列地理指向的限制，使消息按照特定的主題甚至內(nèi)容進(jìn)行分發(fā)，用戶或應(yīng)用程序可以根據(jù)主題或內(nèi)容接收到所需要的消息。發(fā)布/訂閱功能使得發(fā)送者和接收者之間的耦合關(guān)系變得更為松散，發(fā)送者不必關(guān)心接收者的目的地址，而接收者也不必關(guān)心消息的發(fā)送地址，而只是根據(jù)消息的主題進(jìn)行消息的收發(fā)。

群集 (Cluster)：為了簡(jiǎn)化點(diǎn)對(duì)點(diǎn)通訊模式中的系統(tǒng)配置，MQ 提供 Cluster(群集) 的解決方案。群集類似于一個(gè)域 (Domain)，群集內(nèi)部的隊(duì)列管理器之間通訊時(shí)，不需要兩兩之間建立消息通道，而是采用群集 (Cluster) 通道與其它成員通訊，從而大大簡(jiǎn)化了系統(tǒng)配置。此外，群集中的隊(duì)列管理器之間能夠自動(dòng)進(jìn)行負(fù)載均衡，當(dāng)某一隊(duì)列管理器出現(xiàn)故障時(shí)，其它隊(duì)列管理器可以接管它的工作，從而大大提高系統(tǒng)的高可靠性。

Apache Kafka 原理

Kafka 是一個(gè)消息系統(tǒng)，原本開發(fā)自 LinkedIn，用作 LinkedIn 的活動(dòng)流（Activity Stream）和運(yùn)營(yíng)數(shù)據(jù)處理管道（Pipeline）的基礎(chǔ)。現(xiàn)在它已被多家公司作為多種類型的數(shù)據(jù)管道和消息系統(tǒng)使用。活動(dòng)流數(shù)據(jù)是幾乎所有站點(diǎn)在對(duì)其網(wǎng)站使用情況做報(bào)表時(shí)都要用到的數(shù)據(jù)中最常規(guī)的部分。活動(dòng)數(shù)據(jù)包括頁(yè)面訪問(wèn)量（Page View）、被查看內(nèi)容方面的信息以及搜索情況等內(nèi)容。這種數(shù)據(jù)通常的處理方式是先把各種活動(dòng)以日志的形式寫入某種文件，然后周期性地對(duì)這些文件進(jìn)行統(tǒng)計(jì)分析。運(yùn)營(yíng)數(shù)據(jù)指的是服務(wù)器的性能數(shù)據(jù)（CPU、IO 使用率、請(qǐng)求時(shí)間、服務(wù)日志等等數(shù)據(jù))，總的來(lái)說(shuō)，運(yùn)營(yíng)數(shù)據(jù)的統(tǒng)計(jì)方法種類繁多。

Kafka 專用術(shù)語(yǔ)

• Broker：Kafka 集群包含一個(gè)或多個(gè)服務(wù)器，這種服務(wù)器被稱為 broker。

• Topic：每條發(fā)布到 Kafka 集群的消息都有一個(gè)類別，這個(gè)類別被稱為 Topic。（物理上不同 Topic 的消息分開存儲(chǔ)，邏輯上一個(gè) Topic 的消息雖然保存于一個(gè)或多個(gè) broker 上，但用戶只需指定消息的 Topic 即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）。

• Partition：Partition 是物理上的概念，每個(gè) Topic 包含一個(gè)或多個(gè) Partition。

• Producer：負(fù)責(zé)發(fā)布消息到 Kafka broker。

• Consumer：消息消費(fèi)者，向 Kafka broker 讀取消息的客戶端。

• Consumer Group：每個(gè) Consumer 屬于一個(gè)特定的 Consumer Group（可為每個(gè) Consumer 指定 group name，若不指定 group name 則屬于默認(rèn)的 group）。

Kafka 交互流程

Kafka 是一個(gè)基于分布式的消息發(fā)布-訂閱系統(tǒng)，它被設(shè)計(jì)成快速、可擴(kuò)展的、持久的。與其他消息發(fā)布-訂閱系統(tǒng)類似，Kafka 在主題當(dāng)中保存消息的信息。生產(chǎn)者向主題寫入數(shù)據(jù)，消費(fèi)者從主題讀取數(shù)據(jù)。由于 Kafka 的特性是支持分布式，同時(shí)也是基于分布式的，所以主題也是可以在多個(gè)節(jié)點(diǎn)上被分區(qū)和覆蓋的。

信息是一個(gè)字節(jié)數(shù)組，程序員可以在這些字節(jié)數(shù)組中存儲(chǔ)任何對(duì)象，支持的數(shù)據(jù)格式包括 String、JSON、Avro。Kafka 通過(guò)給每一個(gè)消息綁定一個(gè)鍵值的方式來(lái)保證生產(chǎn)者可以把所有的消息發(fā)送到指定位置。屬于某一個(gè)消費(fèi)者群組的消費(fèi)者訂閱了一個(gè)主題，通過(guò)該訂閱消費(fèi)者可以跨節(jié)點(diǎn)地接收所有與該主題相關(guān)的消息，每一個(gè)消息只會(huì)發(fā)送給群組中的一個(gè)消費(fèi)者，所有擁有相同鍵值的消息都會(huì)被確保發(fā)給這一個(gè)消費(fèi)者。

Kafka 設(shè)計(jì)中將每一個(gè)主題分區(qū)當(dāng)作一個(gè)具有順序排列的日志。同處于一個(gè)分區(qū)中的消息都被設(shè)置了一個(gè)唯一的偏移量。Kafka 只會(huì)保持跟蹤未讀消息，一旦消息被置為已讀狀態(tài)，Kafka 就不會(huì)再去管理它了。Kafka 的生產(chǎn)者負(fù)責(zé)在消息隊(duì)列中對(duì)生產(chǎn)出來(lái)的消息保證一定時(shí)間的占有，消費(fèi)者負(fù)責(zé)追蹤每一個(gè)主題 (可以理解為一個(gè)日志通道) 的消息并及時(shí)獲取它們。基于這樣的設(shè)計(jì)，Kafka 可以在消息隊(duì)列中保存大量的開銷很小的數(shù)據(jù)，并且支持大量的消費(fèi)者訂閱。

利用 Apache Kafka 系統(tǒng)架構(gòu)的設(shè)計(jì)思路

示例：網(wǎng)絡(luò)游戲

假設(shè)我們正在開發(fā)一個(gè)在線網(wǎng)絡(luò)游戲平臺(tái)，這個(gè)平臺(tái)需要支持大量的在線用戶實(shí)時(shí)操作，玩家在一個(gè)虛擬的世界里通過(guò)互相協(xié)作的方式一起完成每一個(gè)任務(wù)。由于游戲當(dāng)中允許玩家互相交易金幣、道具，我們必須確保玩家之間的誠(chéng)信關(guān)系，而為了確保玩家之間的誠(chéng)信及賬戶安全，我們需要對(duì)玩家的 IP 地址進(jìn)行追蹤，當(dāng)出現(xiàn)一個(gè)長(zhǎng)期固定 IP 地址忽然之間出現(xiàn)異動(dòng)情況，我們要能夠預(yù)警，同時(shí)，如果出現(xiàn)玩家所持有的金幣、道具出現(xiàn)重大變更的情況，也要能夠及時(shí)預(yù)警。此外，為了讓開發(fā)組的數(shù)據(jù)工程師能夠測(cè)試新的算法，我們要允許這些玩家數(shù)據(jù)進(jìn)入到 Hadoop 集群，即加載這些數(shù)據(jù)到 Hadoop 集群里面。

對(duì)于一個(gè)實(shí)時(shí)游戲，我們必須要做到對(duì)存儲(chǔ)在服務(wù)器內(nèi)存中的數(shù)據(jù)進(jìn)行快速處理，這樣可以幫助實(shí)時(shí)地發(fā)出預(yù)警等各類動(dòng)作。我們的系統(tǒng)架設(shè)擁有多臺(tái)服務(wù)器，內(nèi)存中的數(shù)據(jù)包括了每一個(gè)在線玩家近 30 次訪問(wèn)的各類記錄，包括道具、交易信息等等，并且這些數(shù)據(jù)跨服務(wù)器存儲(chǔ)。

我們的服務(wù)器擁有兩個(gè)角色：首先是接受用戶發(fā)起的動(dòng)作，例如交易請(qǐng)求，其次是實(shí)時(shí)地處理用戶發(fā)起的交易并根據(jù)交易信息發(fā)起必要的預(yù)警動(dòng)作。為了保證快速、實(shí)時(shí)地處理數(shù)據(jù)，我們需要在每一臺(tái)機(jī)器的內(nèi)存中保留歷史交易信息，這意味著我們必須在服務(wù)器之間傳遞數(shù)據(jù)，即使接收用戶請(qǐng)求的這臺(tái)機(jī)器沒有該用戶的交易信息。為了保證角色的松耦合，我們使用 Kafka 在服務(wù)器之間傳遞信息 (數(shù)據(jù))。

Kafka 特性

Kafka 的幾個(gè)特性非常滿足我們的需求：可擴(kuò)展性、數(shù)據(jù)分區(qū)、低延遲、處理大量不同消費(fèi)者的能力。這個(gè)案例我們可以配置在 Kafka 中為登錄和交易配置同一個(gè)主題。由于 Kafka 支持在單一主題內(nèi)的排序，而不是跨主題的排序，所以我們?yōu)榱吮ＷC用戶在交易前使用實(shí)際的 IP 地址登錄系統(tǒng)，我們采用了同一個(gè)主題來(lái)存儲(chǔ)登錄信息和交易信息。

當(dāng)用戶登錄或者發(fā)起交易動(dòng)作后，負(fù)責(zé)接收的服務(wù)器立即發(fā)事件給 Kafka。這里我們采用用戶 id 作為消息的主鍵，具體事件作為值。這保證了同一個(gè)用戶的所有的交易信息和登錄信息被發(fā)送到 Kafka 分區(qū)。每一個(gè)事件處理服務(wù)被當(dāng)作一個(gè) Kafka 消費(fèi)者來(lái)運(yùn)行，所有的消費(fèi)者被配置到了同一個(gè)消費(fèi)者群組，這樣每一臺(tái)服務(wù)器從一些 Kafka 分區(qū)讀取數(shù)據(jù)，一個(gè)分區(qū)的所有數(shù)據(jù)被送到同一個(gè)事件處理服務(wù)器 (可以與接收服務(wù)器不同)。當(dāng)事件處理服務(wù)器從 Kafka 讀取了用戶交易信息，它可以把該信息加入到保存在本地內(nèi)存中的歷史信息列表里面，這樣可以保證事件處理服務(wù)器在本地內(nèi)存中調(diào)用用戶的歷史信息并做出預(yù)警，而不需要額外的網(wǎng)絡(luò)或磁盤開銷。

圖 1. 游戲設(shè)計(jì)圖

?

為了多線程處理，我們?yōu)槊恳粋€(gè)事件處理服務(wù)器或者每一個(gè)核創(chuàng)建了一個(gè)分區(qū)。Kafka 已經(jīng)在擁有 1 萬(wàn)個(gè)分區(qū)的集群里測(cè)試過(guò)。

切換回 Kafka

上面的例子聽起來(lái)有點(diǎn)繞口：首先從游戲服務(wù)器發(fā)送信息到 Kafka，然后另一臺(tái)游戲服務(wù)器的消費(fèi)者從主題中讀取該信息并處理它。然而，這樣的設(shè)計(jì)解耦了兩個(gè)角色并且允許我們管理每一個(gè)角色的各種功能。此外，這種方式不會(huì)增加負(fù)載到 Kafka。測(cè)試結(jié)果顯示，即使 3 個(gè)結(jié)點(diǎn)組成的集群也可以處理每秒接近百萬(wàn)級(jí)的任務(wù)，平均每個(gè)任務(wù)從注冊(cè)到消費(fèi)耗時(shí) 3 毫秒。

上面例子當(dāng)發(fā)現(xiàn)一個(gè)事件可疑后，發(fā)送一個(gè)預(yù)警標(biāo)志到一個(gè)新的 Kafka 主題，同樣的有一個(gè)消費(fèi)者服務(wù)會(huì)讀取它，并將數(shù)據(jù)存入 Hadoop 集群用于進(jìn)一步的數(shù)據(jù)分析。

因?yàn)?Kafka 不會(huì)追蹤消息的處理過(guò)程及消費(fèi)者隊(duì)列，所以它在消耗極小的前提下可以同時(shí)處理數(shù)千個(gè)消費(fèi)者。Kafka 甚至可以處理批量級(jí)別的消費(fèi)者，例如每小時(shí)喚醒一次一批睡眠的消費(fèi)者來(lái)處理所有的信息。

Kafka 讓數(shù)據(jù)存入 Hadoop 集群變得非常簡(jiǎn)單。當(dāng)擁有多個(gè)數(shù)據(jù)來(lái)源和多個(gè)數(shù)據(jù)目的地時(shí)，為每一個(gè)來(lái)源和目的地配對(duì)地編寫一個(gè)單獨(dú)的數(shù)據(jù)通道會(huì)導(dǎo)致混亂發(fā)生。Kafka 幫助 LinkedIn 規(guī)范了數(shù)據(jù)通道格式，并且允許每一個(gè)系統(tǒng)獲取數(shù)據(jù)和寫入數(shù)據(jù)各一次，這樣極大地減少數(shù)據(jù)通道的復(fù)雜性和操作耗時(shí)。

LinkedIn 的架構(gòu)師 Jay Kreps 說(shuō)：“我最初是在 2008 年完成鍵值對(duì)數(shù)據(jù)存儲(chǔ)方式后開始的，我的項(xiàng)目是嘗試運(yùn)行 Hadoop，將我們的一些處理過(guò)程移動(dòng)到 Hadoop 里面去。我們?cè)谶@個(gè)領(lǐng)域幾乎沒有經(jīng)驗(yàn)，花了幾個(gè)星期嘗試把數(shù)據(jù)導(dǎo)入、導(dǎo)出，另外一些事件花在了嘗試各種各樣的預(yù)測(cè)性算法使用上面，然后，我們開始了漫漫長(zhǎng)路”。

與 Flume 的區(qū)別

Kafka 與 Flume 很多功能確實(shí)是重復(fù)的。以下是評(píng)估兩個(gè)系統(tǒng)的一些建議：

Kafka 是一個(gè)通用型系統(tǒng)。你可以有許多的生產(chǎn)者和消費(fèi)者分享多個(gè)主題。相反地，Flume 被設(shè)計(jì)成特定用途的工作，特定地向 HDFS 和 HBase 發(fā)送出去。Flume 為了更好地為 HDFS 服務(wù)而做了特定的優(yōu)化，并且與 Hadoop 的安全體系整合在了一起。基于這樣的結(jié)論，Hadoop 開發(fā)商 Cloudera 推薦如果數(shù)據(jù)需要被多個(gè)應(yīng)用程序消費(fèi)的話，推薦使用 Kafka，如果數(shù)據(jù)只是面向 Hadoop 的，可以使用 Flume。

Flume 擁有許多配置的來(lái)源 (sources) 和存儲(chǔ)池 (sinks)。然后，Kafka 擁有的是非常小的生產(chǎn)者和消費(fèi)者環(huán)境體系，Kafka 社區(qū)并不是非常支持這樣。如果你的數(shù)據(jù)來(lái)源已經(jīng)確定，不需要額外的編碼，那你可以使用 Flume 提供的 sources 和 sinks，反之，如果你需要準(zhǔn)備自己的生產(chǎn)者和消費(fèi)者，那你需要使用 Kafka。

Flume 可以在攔截器里面實(shí)時(shí)處理數(shù)據(jù)。這個(gè)特性對(duì)于過(guò)濾數(shù)據(jù)非常有用。Kafka 需要一個(gè)外部系統(tǒng)幫助處理數(shù)據(jù)。

無(wú)論是 Kafka 或是 Flume，兩個(gè)系統(tǒng)都可以保證不丟失數(shù)據(jù)。然后，Flume 不會(huì)復(fù)制事件。相應(yīng)地，即使我們正在使用一個(gè)可以信賴的文件通道，如果 Flume agent 所在的這個(gè)節(jié)點(diǎn)宕機(jī)了，你會(huì)失去所有的事件訪問(wèn)能力直到你修復(fù)這個(gè)受損的節(jié)點(diǎn)。使用 Kafka 的管道特性不會(huì)有這樣的問(wèn)題。

Flume 和 Kafka 可以一起工作的。如果你需要把流式數(shù)據(jù)從 Kafka 轉(zhuǎn)移到 Hadoop，可以使用 Flume 代理 (agent)，將 kafka 當(dāng)作一個(gè)來(lái)源 (source)，這樣可以從 Kafka 讀取數(shù)據(jù)到 Hadoop。你不需要去開發(fā)自己的消費(fèi)者，你可以使用 Flume 與 Hadoop、HBase 相結(jié)合的特性，使用 Cloudera Manager 平臺(tái)監(jiān)控消費(fèi)者，并且通過(guò)增加過(guò)濾器的方式處理數(shù)據(jù)。

結(jié)束語(yǔ)

綜上所述，Kafka 的設(shè)計(jì)可以幫助我們解決很多架構(gòu)上的問(wèn)題。但是想要用好 Kafka 的高性能、低耦合、高可靠性、數(shù)據(jù)不丟失等特性，我們需要非常了解 Kafka，以及我們自身的應(yīng)用系統(tǒng)使用場(chǎng)景，并不是任何環(huán)境 Kafka 都是最佳選擇。

?

?

?

?

?

總結(jié)

以上是生活随笔為你收集整理的转-Apache kafka 工作原理介绍的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。