共計(jì) 3854 個(gè)字符，預(yù)計(jì)需要花費(fèi) 10 分鐘才能閱讀完成。
這期內(nèi)容當(dāng)中丸趣 TV 小編將會(huì)給大家?guī)?lái)有關(guān) kafka 分析與單機(jī)使用記錄是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
1. 使用的系統(tǒng)環(huán)境
root@heidsoft:~# uname -a
Linux heidsoft 4.4.0-63-generic #84-Ubuntu SMP Wed Feb 1 17:20:32 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
2.JDK 環(huán)境
root@heidsoft:~# java -version
java version 1.8.0_131
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
3. 軟件版本環(huán)境
4. 配置文件環(huán)境
kafka : server.properties 默認(rèn)配置
zookeeper : zoo.cfg 默認(rèn)配置
5. 啟動(dòng)應(yīng)用
zookeeper: sh zkServer.sh start
kafka: bin/kafka-server-start.sh config/server.properties
6.kafka 測(cè)試
生產(chǎn)者測(cè)試 – 發(fā)送消息
echo Hello, World | bin/kafka-console-producer.sh –broker-list localhost:9092 –topic TutorialTopic /dev/null
消費(fèi)者測(cè)試 – 接收消息
bin/kafka-console-consumer.sh –new-consumer –topic TutorialTopic –from-beginning –bootstrap-server localhost:9092
7.ShowDemo
8. 概念認(rèn)識(shí)
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
Parition 是物理上的概念，每個(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）。
9. 框架認(rèn)識(shí)
Kafka 是分布式發(fā)布 - 訂閱消息系統(tǒng)。它最初由 LinkedIn 公司開發(fā)，之后成為 Apache 項(xiàng)目的一部分。Kafka 是一個(gè)分布式的，可劃分的，冗余備份的持久性的日志服務(wù)。它主要用于處理活躍的流式數(shù)據(jù)。
在大數(shù)據(jù)系統(tǒng)中，常常會(huì)碰到一個(gè)問(wèn)題，整個(gè)大數(shù)據(jù)是由各個(gè)子系統(tǒng)組成，數(shù)據(jù)需要在各個(gè)子系統(tǒng)中高性能，低延遲的不停流轉(zhuǎn)。傳統(tǒng)的企業(yè)消息系統(tǒng)并不是非常適合大規(guī)模的數(shù)據(jù)處理。為了已在同時(shí)搞定在線應(yīng)用（消息）和離線應(yīng)用（數(shù)據(jù)文件，日志）Kafka 就出現(xiàn)了。Kafka 可以起到兩個(gè)作用：
降低系統(tǒng)組網(wǎng)復(fù)雜度。
降低編程復(fù)雜度，各個(gè)子系統(tǒng)不在是相互協(xié)商接口，各個(gè)子系統(tǒng)類似插口插在插座上，Kafka 承擔(dān)高速數(shù)據(jù)總線的作用。
10. 框架特點(diǎn)
同時(shí)為發(fā)布和訂閱提供高吞吐量。據(jù)了解，Kafka 每秒可以生產(chǎn)約 25 萬(wàn)消息（50 MB），每秒處理 55 萬(wàn)消息（110 MB）。
可進(jìn)行持久化操作。將消息持久化到磁盤，因此可用于批量消費(fèi)，例如 ETL，以及實(shí)時(shí)應(yīng)用程序。通過(guò)將數(shù)據(jù)持久化到硬盤以及 replication 防止數(shù)據(jù)丟失。
分布式系統(tǒng)，易于向外擴(kuò)展。所有的 producer、broker 和 consumer 都會(huì)有多個(gè)，均為分布式的。無(wú)需停機(jī)即可擴(kuò)展機(jī)器。
消息被處理的狀態(tài)是在 consumer 端維護(hù)，而不是由 server 端維護(hù)。當(dāng)失敗時(shí)能自動(dòng)平衡。
支持 online 和 offline 的場(chǎng)景。
12.Kafka 拓?fù)浣Y(jié)構(gòu)
如上圖所示，一個(gè)典型的 Kafka 集群中包含若干 Producer（可以是 web 前端產(chǎn)生的 Page View，或者是服務(wù)器日志，系統(tǒng) CPU、Memory 等），若干 broker（Kafka 支持水平擴(kuò)展，一般 broker 數(shù)量越多，集群吞吐率越高），若干 Consumer Group，以及一個(gè) Zookeeper 集群。Kafka 通過(guò) Zookeeper 管理集群配置，選舉 leader，以及在 Consumer Group 發(fā)生變化時(shí)進(jìn)行 rebalance。Producer 使用 push 模式將消息發(fā)布到 broker，Consumer 使用 pull 模式從 broker 訂閱并消費(fèi)消息。
13.Kafka 的設(shè)計(jì)
1、吞吐量
高吞吐是 kafka 需要實(shí)現(xiàn)的核心目標(biāo)之一，為此 kafka 做了以下一些設(shè)計(jì)：
數(shù)據(jù)磁盤持久化：消息不在內(nèi)存中 cache，直接寫入到磁盤，充分利用磁盤的順序讀寫性能
zero-copy：減少 IO 操作步驟
數(shù)據(jù)批量發(fā)送
數(shù)據(jù)壓縮
Topic 劃分為多個(gè) partition，提高 parallelism
負(fù)載均衡
producer 根據(jù)用戶指定的算法，將消息發(fā)送到指定的 partition
存在多個(gè) partiiton，每個(gè) partition 有自己的 replica，每個(gè) replica 分布在不同的 Broker 節(jié)點(diǎn)上
多個(gè) partition 需要選取出 lead partition，lead partition 負(fù)責(zé)讀寫，并由 zookeeper 負(fù)責(zé) fail over
通過(guò) zookeeper 管理 broker 與 consumer 的動(dòng)態(tài)加入與離開
拉取系統(tǒng)
由于 kafka broker 會(huì)持久化數(shù)據(jù)，broker 沒有內(nèi)存壓力，因此，consumer 非常適合采取 pull 的方式消費(fèi)數(shù)據(jù)，具有以下幾點(diǎn)好處：
簡(jiǎn)化 kafka 設(shè)計(jì)
consumer 根據(jù)消費(fèi)能力自主控制消息拉取速度
consumer 根據(jù)自身情況自主選擇消費(fèi)模式，例如批量，重復(fù)消費(fèi)，從尾端開始消費(fèi)等
可擴(kuò)展性
當(dāng)需要增加 broker 結(jié)點(diǎn)時(shí)，新增的 broker 會(huì)向 zookeeper 注冊(cè)，而 producer 及 consumer 會(huì)根據(jù)注冊(cè)在 zookeeper 上的 watcher 感知這些變化，并及時(shí)作出調(diào)整。
Kafka 的應(yīng)用場(chǎng)景
1. 消息隊(duì)列
比起大多數(shù)的消息系統(tǒng)來(lái)說(shuō)，Kafka 有更好的吞吐量，內(nèi)置的分區(qū)，冗余及容錯(cuò)性，這讓 Kafka 成為了一個(gè)很好的大規(guī)模消息處理應(yīng)用的解決方案。消息系統(tǒng)一般吞吐量相對(duì)較低，但是需要更小的端到端延時(shí)，并嘗嘗依賴于 Kafka 提供的強(qiáng)大的持久性保障。在這個(gè)領(lǐng)域，Kafka 足以媲美傳統(tǒng)消息系統(tǒng)，如 ActiveMR 或 RabbitMQ。
2. 行為跟蹤
Kafka 的另一個(gè)應(yīng)用場(chǎng)景是跟蹤用戶瀏覽頁(yè)面、搜索及其他行為，以發(fā)布 - 訂閱的模式實(shí)時(shí)記錄到對(duì)應(yīng)的 topic 里。那么這些結(jié)果被訂閱者拿到后，就可以做進(jìn)一步的實(shí)時(shí)處理，或?qū)崟r(shí)監(jiān)控，或放到 Hadoop/ 離線數(shù)據(jù)倉(cāng)庫(kù)里處理。
3. 元信息監(jiān)控
作為操作記錄的監(jiān)控模塊來(lái)使用，即匯集記錄一些操作信息，可以理解為運(yùn)維性質(zhì)的數(shù)據(jù)監(jiān)控吧。
4. 日志收集
日志收集方面，其實(shí)開源產(chǎn)品有很多，包括 Scribe、Apache Flume。很多人使用 Kafka 代替日志聚合（log aggregation）。日志聚合一般來(lái)說(shuō)是從服務(wù)器上收集日志文件，然后放到一個(gè)集中的位置（文件服務(wù)器或 HDFS）進(jìn)行處理。然而 Kafka 忽略掉文件的細(xì)節(jié)，將其更清晰地抽象成一個(gè)個(gè)日志或事件的消息流。這就讓 Kafka 處理過(guò)程延遲更低，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的系統(tǒng)比如 Scribe 或者 Flume 來(lái)說(shuō)，Kafka 提供同樣高效的性能和因?yàn)閺?fù)制導(dǎo)致的更高的耐用性保證，以及更低的端到端延遲。
5. 流處理
這個(gè)場(chǎng)景可能比較多，也很好理解。保存收集流數(shù)據(jù)，以提供之后對(duì)接的 Storm 或其他流式計(jì)算框架進(jìn)行處理。很多用戶會(huì)將那些從原始 topic 來(lái)的數(shù)據(jù)進(jìn)行階段性處理，匯總，擴(kuò)充或者以其他的方式轉(zhuǎn)換到新的 topic 下再繼續(xù)后面的處理。例如一個(gè)文章推薦的處理流程，可能是先從 RSS 數(shù)據(jù)源中抓取文章的內(nèi)容，然后將其丟入一個(gè)叫做“文章”的 topic 中；后續(xù)操作可能是需要對(duì)這個(gè)內(nèi)容進(jìn)行清理，比如回復(fù)正常數(shù)據(jù)或者刪除重復(fù)數(shù)據(jù)，最后再將內(nèi)容匹配的結(jié)果返還給用戶。這就在一個(gè)獨(dú)立的 topic 之外，產(chǎn)生了一系列的實(shí)時(shí)數(shù)據(jù)處理的流程。Strom 和 Samza 是非常著名的實(shí)現(xiàn)這種類型數(shù)據(jù)轉(zhuǎn)換的框架。
6. 事件源
事件源是一種應(yīng)用程序設(shè)計(jì)的方式，該方式的狀態(tài)轉(zhuǎn)移被記錄為按時(shí)間順序排序的記錄序列。Kafka 可以存儲(chǔ)大量的日志數(shù)據(jù)，這使得它成為一個(gè)對(duì)這種方式的應(yīng)用來(lái)說(shuō)絕佳的后臺(tái)。比如動(dòng)態(tài)匯總（News feed）。
7. 持久性日志（commit log）
Kafka 可以為一種外部的持久性日志的分布式系統(tǒng)提供服務(wù)。這種日志可以在節(jié)點(diǎn)間備份數(shù)據(jù)，并為故障節(jié)點(diǎn)數(shù)據(jù)回復(fù)提供一種重新同步的機(jī)制。Kafka 中日志壓縮功能為這種用法提供了條件。在這種用法中，Kafka 類似于 Apache BookKeeper 項(xiàng)目。
上述就是丸趣 TV 小編為大家分享的 kafka 分析與單機(jī)使用記錄是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
