簡(jiǎn)介

Apache Kafka是分布式發(fā)布-訂閱消息系統(tǒng)。它最初由LinkedIn公司開(kāi)發(fā)，之后成為Apache項(xiàng)目的一部分。Kafka是一種快速、可擴(kuò)展的、設(shè)計(jì)內(nèi)在就是分布式的，分區(qū)的和可復(fù)制的提交日志服務(wù)。

Apache Kafka與傳統(tǒng)消息系統(tǒng)相比，有以下不同：

它被設(shè)計(jì)為一個(gè)分布式系統(tǒng)，易于向外擴(kuò)展；

它同時(shí)為發(fā)布和訂閱提供高吞吐量；

它支持多訂閱者，當(dāng)失敗時(shí)能自動(dòng)平衡消費(fèi)者；

它將消息持久化到磁盤，因此可用于批量消費(fèi)，例如 ETL，以及實(shí)時(shí)應(yīng)用程序。

本文我將重點(diǎn)介紹Apache Kafka的架構(gòu)、特性和特點(diǎn)，幫助我們理解Kafka為何比傳統(tǒng)消息服務(wù)更好。

我將比較Kafak和傳統(tǒng)消息服務(wù) RabbitMQ、Apache ActiveMQ的特點(diǎn)，討論一些Kafka優(yōu)于傳統(tǒng)消息服務(wù)的場(chǎng)景。在最后一節(jié)，我們將探討一個(gè)進(jìn)行中的示例應(yīng)用，展示Kafka作為消息服務(wù)器的用途。這個(gè)示例應(yīng)用的完整源代碼在 GitHub。關(guān)于它的詳細(xì)討論在本文的最后一節(jié)。

架構(gòu)

首先，我介紹一下Kafka的基本概念。它的架構(gòu)包括以下組件：

話題（Topic）是特定類型的 消息流。 消息是字節(jié)的有效負(fù)載（Payload），話題是消息的分類名或種子（Feed）名。

生產(chǎn)者（Producer）是能夠發(fā)布消息到話題的任何對(duì)象。

已發(fā)布的消息保存在一組服務(wù)器中，它們被稱為 代理（Broker）或Kafka集群。

消費(fèi)者可以訂閱一個(gè)或多個(gè)話題，并從Broker拉數(shù)據(jù)，從而消費(fèi)這些已發(fā)布的消息。

圖1：Kafka生產(chǎn)者、消費(fèi)者和代理環(huán)境

生產(chǎn)者可以選擇自己喜歡的序列化方法對(duì)消息內(nèi)容編碼。為了提高效率，生產(chǎn)者可以在一個(gè)發(fā)布請(qǐng)求中發(fā)送一組消息。下面的代碼演示了如何創(chuàng)建生產(chǎn)者并發(fā)送消息。

生產(chǎn)者示例代碼：

producer = new Producer(…);

message = new Message(“test message str”.getBytes());

set = new MessageSet(message);

producer.send(“topic1”, set);

為了訂閱話題，消費(fèi)者首先為話題創(chuàng)建一個(gè)或多個(gè)消息流。發(fā)布到該話題的消息將被均衡地分發(fā)到這些流。每個(gè)消息流為不斷產(chǎn)生的消息提供了迭代接 口。然后消費(fèi)者迭代流中的每一條消息，處理消息的有效負(fù)載。與傳統(tǒng)迭代器不同，消息流迭代器永不停止。如果當(dāng)前沒(méi)有消息，迭代器將阻塞，直到有新的消息發(fā) 布到該話題。Kafka同時(shí)支持點(diǎn)到點(diǎn)分發(fā)模型（Point-to-point delivery model），即多個(gè)消費(fèi)者共同消費(fèi)隊(duì)列中某個(gè)消息的單個(gè)副本，以及發(fā)布-訂閱模型（Publish-subscribe model），即多個(gè)消費(fèi)者接收自己的消息副本。下面的代碼演示了消費(fèi)者如何使用消息。

消費(fèi)者示例代碼：

streams[] = Consumer.createMessageStreams(“topic1”, 1)

for (message : streams[0]) {

bytes = message.payload();

// do something with the bytes

}

Kafka的整體架構(gòu)如圖2所示。因?yàn)镵afka內(nèi)在就是分布式的，一個(gè)Kafka集群通常包括多個(gè)代理。為了均衡負(fù)載，將話題分成多個(gè)分區(qū)，每個(gè)代理存儲(chǔ)一或多個(gè)分區(qū)。多個(gè)生產(chǎn)者和消費(fèi)者能夠同時(shí)生產(chǎn)和獲取消息。

圖2：Kafka架構(gòu)

很多初學(xué)者，對(duì)大數(shù)據(jù)的概念都是模糊不清的，大數(shù)據(jù)是什么，能做什么，學(xué)的時(shí)候，該按照什么線路去學(xué)習(xí)，學(xué)完往哪方面發(fā)展，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)扣扣群：740041381，有大量干貨（零基礎(chǔ)以及進(jìn)階的經(jīng)典實(shí)戰(zhàn)）分享給大家，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費(fèi)授課，給大家分享目前國(guó)內(nèi)最完整的大數(shù)據(jù)高端實(shí)戰(zhàn)實(shí)用學(xué)習(xí)流程體系。

Kafka存儲(chǔ)

Kafka的存儲(chǔ)布局非常簡(jiǎn)單。話題的每個(gè)分區(qū)對(duì)應(yīng)一個(gè)邏輯日志。物理上，一個(gè)日志為相同大小的一組分段文件。每次生產(chǎn)者發(fā)布消息到一個(gè)分區(qū)， 代理就將消息追加到最后一個(gè)段文件中。當(dāng)發(fā)布的消息數(shù)量達(dá)到設(shè)定值或者經(jīng)過(guò)一定的時(shí)間后，段文件真正寫入磁盤中。寫入完成后，消息公開(kāi)給消費(fèi)者。

與傳統(tǒng)的消息系統(tǒng)不同，Kafka系統(tǒng)中存儲(chǔ)的消息沒(méi)有明確的消息Id。

消息通過(guò)日志中的邏輯偏移量來(lái)公開(kāi)。這樣就避免了維護(hù)配套密集尋址，用于映射消息ID到實(shí)際消息地址的隨機(jī)存取索引結(jié)構(gòu)的開(kāi)銷。消息ID是增量的，但不連續(xù)。要計(jì)算下一消息的ID，可以在其邏輯偏移的基礎(chǔ)上加上當(dāng)前消息的長(zhǎng)度。

消費(fèi)者始終從特定分區(qū)順序地獲取消息，如果消費(fèi)者知道特定消息的偏移量，也就說(shuō)明消費(fèi)者已經(jīng)消費(fèi)了之前的所有消息。消費(fèi)者向代理發(fā)出異步拉請(qǐng)求，準(zhǔn)備字節(jié)緩沖區(qū)用于消費(fèi)。每個(gè)異步拉請(qǐng)求都包含要消費(fèi)的消息偏移量。Kafka利用 sendfile API高效地從代理的日志段文件中分發(fā)字節(jié)給消費(fèi)者。

圖3：Kafka存儲(chǔ)架構(gòu)

Kafka代理

與其它消息系統(tǒng)不同，Kafka代理是無(wú)狀態(tài)的。這意味著消費(fèi)者必須維護(hù)已消費(fèi)的狀態(tài)信息。這些信息由消費(fèi)者自己維護(hù)，代理完全不管。這種設(shè)計(jì)非常微妙，它本身包含了創(chuàng)新。

從代理刪除消息變得很棘手，因?yàn)榇聿⒉恢老M(fèi)者是否已經(jīng)使用了該消息。Kafka創(chuàng)新性地解決了這個(gè)問(wèn)題，它將一個(gè)簡(jiǎn)單的基于時(shí)間的SLA應(yīng)用于保留策略。當(dāng)消息在代理中超過(guò)一定時(shí)間后，將會(huì)被自動(dòng)刪除。

這種創(chuàng)新設(shè)計(jì)有很大的好處，消費(fèi)者可以故意倒回到老的偏移量再次消費(fèi)數(shù)據(jù)。這違反了隊(duì)列的常見(jiàn)約定，但被證明是許多消費(fèi)者的基本特征。

ZooKeeper與Kafka

考慮一下有多個(gè)服務(wù)器的分布式系統(tǒng)，每臺(tái)服務(wù)器都負(fù)責(zé)保存數(shù)據(jù)，在數(shù)據(jù)上執(zhí)行操作。這樣的潛在例子包括分布式搜索引擎、分布式構(gòu)建系統(tǒng)或者已知的系統(tǒng)如 Apache Hadoop。 所有這些分布式系統(tǒng)的一個(gè)常見(jiàn)問(wèn)題是，你如何在任一時(shí)間點(diǎn)確定哪些服務(wù)器活著并且在工作中。最重要的是，當(dāng)面對(duì)這些分布式計(jì)算的難題，例如網(wǎng)絡(luò)失敗、帶寬 限制、可變延遲連接、安全問(wèn)題以及任何網(wǎng)絡(luò)環(huán)境，甚至跨多個(gè)數(shù)據(jù)中心時(shí)可能發(fā)生的錯(cuò)誤時(shí)，你如何可靠地做這些事。這些正是 Apache ZooKeeper所 關(guān)注的問(wèn)題，它是一個(gè)快速、高可用、容錯(cuò)、分布式的協(xié)調(diào)服務(wù)。你可以使用ZooKeeper構(gòu)建可靠的、分布式的數(shù)據(jù)結(jié)構(gòu)，用于群組成員、領(lǐng)導(dǎo)人選舉、協(xié) 同工作流和配置服務(wù)，以及廣義的分布式數(shù)據(jù)結(jié)構(gòu)如鎖、隊(duì)列、屏障（Barrier）和鎖存器（Latch）。許多知名且成功的項(xiàng)目依賴于 ZooKeeper，其中包括HBase、Hadoop 2.0、Solr Cloud、Neo4J、 Apache Blur（Incubating）和Accumulo。

ZooKeeper是一個(gè)分布式的、分層級(jí)的文件系統(tǒng)，能促進(jìn)客戶端間的松耦合，并提供最終一致的，類似于傳統(tǒng)文件系統(tǒng)中文件和目錄的 Znode視圖。它提供了基本的操作，例如創(chuàng)建、刪除和檢查Znode是否存在。它提供了事件驅(qū)動(dòng)模型，客戶端能觀察特定Znode的變化，例如現(xiàn)有 Znode增加了一個(gè)新的子節(jié)點(diǎn)。ZooKeeper運(yùn)行多個(gè)ZooKeeper服務(wù)器，稱為 Ensemble，以獲得高可用性。每個(gè)服務(wù)器都持有分布式文件系統(tǒng)的內(nèi)存復(fù)本，為客戶端的讀取請(qǐng)求提供服務(wù)。

圖4：ZooKeeper Ensemble架構(gòu)

上圖4展示了典型的ZooKeeper ensemble，一臺(tái)服務(wù)器作為L(zhǎng)eader，其它作為Follower。當(dāng)Ensemble啟動(dòng)時(shí)，先選出Leader，然后所有Follower復(fù) 制Leader的狀態(tài)。所有寫請(qǐng)求都通過(guò)Leader路由，變更會(huì)廣播給所有Follower。變更廣播被稱為 原子廣播。

Kafka中ZooKeeper的用途：正如ZooKeeper用于分布式系統(tǒng)的協(xié)調(diào)和促 進(jìn)，Kafka使用ZooKeeper也是基于相同的原因。ZooKeeper用于管理、協(xié)調(diào)Kafka代理。每個(gè)Kafka代理都通過(guò) ZooKeeper協(xié)調(diào)其它Kafka代理。當(dāng)Kafka系統(tǒng)中新增了代理或者某個(gè)代理故障失效時(shí)，ZooKeeper服務(wù)將通知生產(chǎn)者和消費(fèi)者。生產(chǎn)者 和消費(fèi)者據(jù)此開(kāi)始與其它代理協(xié)調(diào)工作。Kafka整體系統(tǒng)架構(gòu)如圖5所示。

圖5：Kafka分布式系統(tǒng)的總體架構(gòu)

Apache Kafka對(duì)比其它消息服務(wù)

讓我們了解一下使用Apache Kafka的兩個(gè)項(xiàng)目，以對(duì)比其它消息服務(wù)。這兩個(gè)項(xiàng)目分別是LinkedIn和我的項(xiàng)目：

LinkedIn的研究

LinkedIn團(tuán)隊(duì)做了個(gè) 實(shí)驗(yàn)研究，對(duì)比Kafka與Apache ActiveMQ V5.4和RabbitMQ V2.4的性能。他們使用ActiveMQ默認(rèn)的消息持久化庫(kù) Kahadb。LinkedIn在兩臺(tái)Linux機(jī)器上運(yùn)行他們的實(shí)驗(yàn)，每臺(tái)機(jī)器的配置為8核2GHz、16GB內(nèi)存，6個(gè)磁盤使用RAID10。兩臺(tái)機(jī)器通過(guò)1GB網(wǎng)絡(luò)連接。一臺(tái)機(jī)器作為代理，另一臺(tái)作為生產(chǎn)者或者消費(fèi)者。

生產(chǎn)者測(cè)試

LinkedIn團(tuán)隊(duì)在所有系統(tǒng)中配置代理，異步將消息刷入其持久化庫(kù)。對(duì)每個(gè)系統(tǒng)，運(yùn)行一個(gè)生產(chǎn)者，總共發(fā)布1000萬(wàn)條消息，每條消息 200字節(jié)。Kafka生產(chǎn)者以1和50批量方式發(fā)送消息。ActiveMQ和RabbitMQ似乎沒(méi)有簡(jiǎn)單的辦法來(lái)批量發(fā)送消息，LinkedIn假定 它的批量值為1。結(jié)果如下面的圖6所示：

圖6：LinkedIn的生產(chǎn)者性能實(shí)驗(yàn)結(jié)果

Kafka性能要好很多的主要原因包括：

Kafka不等待代理的確認(rèn)，以代理能處理的最快速度發(fā)送消息。

Kafka有更高效的存儲(chǔ)格式。平均而言，Kafka每條消息有9字節(jié)的開(kāi)銷，而ActiveMQ有144字節(jié)。其原因是JMS所需的沉重 消息頭，以及維護(hù)各種索引結(jié)構(gòu)的開(kāi)銷。LinkedIn注意到ActiveMQ一個(gè)最忙的線程大部分時(shí)間都在存取B-Tree以維護(hù)消息元數(shù)據(jù)和狀態(tài)。

消費(fèi)者測(cè)試

很多初學(xué)者，對(duì)大數(shù)據(jù)的概念都是模糊不清的，大數(shù)據(jù)是什么，能做什么，學(xué)的時(shí)候，該按照什么線路去學(xué)習(xí)，學(xué)完往哪方面發(fā)展，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)扣扣群：740041381，有大量干貨（零基礎(chǔ)以及進(jìn)階的經(jīng)典實(shí)戰(zhàn)）分享給大家，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費(fèi)授課，給大家分享目前國(guó)內(nèi)最完整的大數(shù)據(jù)高端實(shí)戰(zhàn)實(shí)用學(xué)習(xí)流程體系

為了做消費(fèi)者測(cè)試，LinkedIn使用一個(gè)消費(fèi)者獲取總共1000萬(wàn)條消息。LinkedIn讓所有系統(tǒng)每次拉請(qǐng)求都預(yù)獲取大約相同數(shù)量的數(shù) 據(jù)，最多1000條消息或者200KB。對(duì)ActiveMQ和RabbitMQ，LinkedIn設(shè)置消費(fèi)者確認(rèn)模型為自動(dòng)。結(jié)果如圖7所示。

圖7：LinkedIn的消費(fèi)者性能實(shí)驗(yàn)結(jié)果

Kafka性能要好很多的主要原因包括：

Kafka有更高效的存儲(chǔ)格式；在Kafka中，從代理傳輸?shù)较M(fèi)者的字節(jié)更少。

ActiveMQ和RabbitMQ兩個(gè)容器中的代理必須維護(hù)每個(gè)消息的傳輸狀態(tài)。LinkedIn團(tuán)隊(duì)注意到其中一個(gè)ActiveMQ線 程在測(cè)試過(guò)程中，一直在將KahaDB頁(yè)寫入磁盤。與此相反，Kafka代理沒(méi)有磁盤寫入動(dòng)作。最后，Kafka通過(guò)使用sendfile API降低了傳輸開(kāi)銷。

目前，我正在工作的一個(gè)項(xiàng)目提供實(shí)時(shí)服務(wù)，從消息中快速并準(zhǔn)確地提取場(chǎng)外交易市場(chǎng)（OTC）定價(jià)內(nèi)容。這是一個(gè)非常重要的項(xiàng)目，處理近25種資 產(chǎn)類別的財(cái)務(wù)信息，包括債券、貸款和ABS（資產(chǎn)擔(dān)保證券）。項(xiàng)目的原始信息來(lái)源涵蓋了歐洲、北美、加拿大和拉丁美洲的主要金融市場(chǎng)領(lǐng)域。下面是這個(gè)項(xiàng)目 的一些統(tǒng)計(jì)，說(shuō)明了解決方案中包括高效的分布式消息服務(wù)是多么重要：

每天處理的消息數(shù)量超過(guò) 1,300,000；

每天解析的OTC價(jià)格數(shù)量超過(guò) 12,000,000；

支持超過(guò)25種資產(chǎn)類別；

每天解析的獨(dú)立票據(jù)超過(guò) 70,000。

消息包含PDF、Word文檔、Excel及其它格式。OTC定價(jià)也可能要從附件中提取。

由于傳統(tǒng)消息服務(wù)器的性能限制，當(dāng)處理大附件時(shí)，消息隊(duì)列變得非常大，我們的項(xiàng)目面臨嚴(yán)重的問(wèn)題，JMSqueue一天需要啟動(dòng)2-3次。重啟 JMS隊(duì)列可能丟失隊(duì)列中的全部消息。項(xiàng)目需要一個(gè)框架，不論解析器（消費(fèi)者）的行為如何，都能夠保住消息。Kafka的特性非常適用于我們項(xiàng)目的需求。

當(dāng)前項(xiàng)目具備的特性：

使用Fetchmail獲取遠(yuǎn)程郵件消息，然后由Procmail過(guò)濾并處理，例如單獨(dú)分發(fā)基于附件的消息。

每條消息從單獨(dú)的文件獲取，該文件被處理（讀取和刪除）為一條消息插入到消息服務(wù)器中。

消息內(nèi)容從消息服務(wù)隊(duì)列中獲取，用于解析和提取信息。

示例應(yīng)用

這個(gè)示例應(yīng)用是基于我在項(xiàng)目中使用的原始應(yīng)用修改后的版本。我已經(jīng)刪除日志的使用和多線程特性，使示例應(yīng)用的工件盡量簡(jiǎn)單。示例應(yīng)用的目的是展示如何使用Kafka生產(chǎn)者和消費(fèi)者的API。應(yīng)用包括一個(gè) 生產(chǎn)者示例（簡(jiǎn)單的生產(chǎn)者代碼，演示Kafka生產(chǎn)者API用法并發(fā)布特定話題的消息）， 消費(fèi)者示例（簡(jiǎn)單的消費(fèi)者代碼，用于演示Kafka消費(fèi)者API的用法）以及 消息內(nèi)容生成API（在特定路徑下生成消息內(nèi)容到文件的API）。下圖展示了各組件以及它們與系統(tǒng)中其它組件間的關(guān)系。

圖8：示例應(yīng)用組件架構(gòu)

示例應(yīng)用的結(jié)構(gòu)與Kafka源代碼中的例子程序相似。應(yīng)用的源代碼包含Java源程序文件夾‘src’和'config'文件夾，后者包括幾個(gè)配置文件和一些Shell腳本，用于執(zhí)行示例應(yīng)用。要運(yùn)行示例應(yīng)用，請(qǐng)參照 ReadMe.md文件或GitHub網(wǎng)站 Wiki頁(yè)面的說(shuō)明。

程序構(gòu)建可以使用 Apache Maven，定制也很容易。如果有人想修改或定制示例應(yīng)用的代碼，有幾個(gè)Kafka構(gòu)建腳本已經(jīng)過(guò)修改，可用于重新構(gòu)建示例應(yīng)用代碼。關(guān)于如何定制示例應(yīng)用的詳細(xì)描述已經(jīng)放在項(xiàng)目GitHub的 Wiki頁(yè)面。

現(xiàn)在，讓我們看看示例應(yīng)用的核心工件。

Kafka生產(chǎn)者代碼示例

/**

* Instantiates a new Kafka producer.

*

* @param topic the topic

* @param directoryPath the directory path

*/

public KafkaMailProducer(String topic, String directoryPath) {

props.put("serializer.class", "kafka.serializer.StringEncoder");

props.put("metadata.broker.list", "localhost:9092");

producer = new kafka.javaapi.producer.Producer<Integer, String>(new ProducerConfig(props));

this.topic = topic;

this.directoryPath = directoryPath;

}

public void run() {

Path dir = Paths.get(directoryPath);

try {

new WatchDir(dir).start();

new ReadDir(dir).start();

} catch (IOException e) {

e.printStackTrace();

}

}

上面的代碼片斷展示了Kafka生產(chǎn)者API的基本用法，例如設(shè)置生產(chǎn)者的屬性，包括發(fā)布哪個(gè)話題的消息，可以使用哪個(gè)序列化類以及代理的相關(guān) 信息。這個(gè)類的基本功能是從郵件目錄讀取郵件消息文件，然后作為消息發(fā)布到Kafka代理。目錄通過(guò)java.nio.WatchService類監(jiān)視， 一旦新的郵件消息Dump到該目錄，就會(huì)被立即讀取并作為消息發(fā)布到Kafka代理。

Kafka消費(fèi)者代碼示例

public KafkaMailConsumer(String topic) {

consumer =

Kafka.consumer.Consumer.createJavaConsumerConnector(createConsumerConfig());

this.topic = topic;

}

/**

* Creates the consumer config.

*

* @return the consumer config

*/

private static ConsumerConfig createConsumerConfig() {

Properties props = new Properties();

props.put("zookeeper.connect", KafkaMailProperties.zkConnect);

props.put("group.id", KafkaMailProperties.groupId);

props.put("zookeeper.session.timeout.ms", "400");

props.put("zookeeper.sync.time.ms", "200");

props.put("auto.commit.interval.ms", "1000");

return new ConsumerConfig(props);

}

public void run() {

Map<String, Integer> topicCountMap = new HashMap<String, Integer>();

topicCountMap.put(topic, new Integer(1));

Map<String, List<KafkaStream<byte[], byte[]>>> consumerMap = consumer.createMessageStreams(topicCountMap);

KafkaStream<byte[], byte[]> stream = consumerMap.get(topic).get(0);

ConsumerIterator<byte[], byte[]> it = stream.iterator();

while (it.hasNext())

System.out.println(new String(it.next().message()));

}

很多初學(xué)者，對(duì)大數(shù)據(jù)的概念都是模糊不清的，大數(shù)據(jù)是什么，能做什么，學(xué)的時(shí)候，該按照什么線路去學(xué)習(xí)，學(xué)完往哪方面發(fā)展，想深入了解，想學(xué)習(xí)的同學(xué)歡迎加入大數(shù)據(jù)學(xué)習(xí)扣扣群：740041381，有大量干貨（零基礎(chǔ)以及進(jìn)階的經(jīng)典實(shí)戰(zhàn)）分享給大家，并且有清華大學(xué)畢業(yè)的資深大數(shù)據(jù)講師給大家免費(fèi)授課，給大家分享目前國(guó)內(nèi)最完整的大數(shù)據(jù)高端實(shí)戰(zhàn)實(shí)用學(xué)習(xí)流程體系

上面的代碼演示了基本的消費(fèi)者API。正如我們前面提到的，消費(fèi)者需要設(shè)置消費(fèi)的消息流。在Run方法中，我們進(jìn)行了設(shè)置，并在控制臺(tái)打印收到的消息。在我的項(xiàng)目中，我們將其輸入到解析系統(tǒng)以提取OTC定價(jià)。

在當(dāng)前的質(zhì)量保證系統(tǒng)中，我們使用Kafka作為消息服務(wù)器用于概念驗(yàn)證（Proof of Concept，POC）項(xiàng)目，它的整體性能優(yōu)于JMS消息服務(wù)。其中一個(gè)我們感到非常興奮的特性是消息的再消費(fèi)（re-consumption），這讓 我們的解析系統(tǒng)可以按照業(yè)務(wù)需求重新解析某些消息?；贙afka這些很好的效果，我們正計(jì)劃使用它，而不是用Nagios系統(tǒng)，去做日志聚合與分析。

總結(jié)

Kafka是一種處理大量數(shù)據(jù)的新型系統(tǒng)。Kafka基于拉的消費(fèi)模型讓消費(fèi)者以自己的速度處理消息。如果處理消息時(shí)出現(xiàn)了異常，消費(fèi)者始終可以選擇再消費(fèi)該消息。

轉(zhuǎn)載于:https://blog.51cto.com/14309943/2405117

總結(jié)

以上是生活随笔為你收集整理的大数据开发hadoop核心的分布式消息系统：Apache Kafka 你知道吗的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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