您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關kafka分析與單機使用記錄是怎樣的,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
1.使用的系統環境
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環境
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.軟件版本環境
4.配置文件環境
kafka : server.properties 默認配置
zookeeper : zoo.cfg 默認配置
5.啟動應用
zookeeper: sh zkServer.sh start
kafka: bin/kafka-server-start.sh config/server.properties &
6.kafka 測試
生產者測試--發送消息
echo "Hello, World" | bin/kafka-console-producer.sh --broker-list localhost:9092 --topic TutorialTopic > /dev/null
消費者測試--接收消息
bin/kafka-console-consumer.sh --new-consumer --topic TutorialTopic --from-beginning --bootstrap-server localhost:9092
7.ShowDemo
8.概念認識
Broker
Kafka集群包含一個或多個服務器,這種服務器被稱為broker
Topic
每條發布到Kafka集群的消息都有一個類別,這個類別被稱為Topic。(物理上不同Topic的消息分開存儲,邏輯上一個Topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存于何處)
Partition
Parition是物理上的概念,每個Topic包含一個或多個Partition.
Producer
負責發布消息到Kafka broker
Consumer
消息消費者,向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬于一個特定的Consumer Group(可為每個Consumer指定group name,若不指定group name則屬于默認的group)。
9.框架認識
Kafka是分布式發布-訂閱消息系統。它最初由LinkedIn公司開發,之后成為Apache項目的一部分。Kafka是一個分布式的,可劃分的,冗余備份的持久性的日志服務。它主要用于處理活躍的流式數據。
在大數據系統中,常常會碰到一個問題,整個大數據是由各個子系統組成,數據需要在各個子系統中高性能,低延遲的不停流轉。傳統的企業消息系統并不是非常適合大規模的數據處理。為了已在同時搞定在線應用(消息)和離線應用(數據文件,日志)Kafka就出現了。Kafka可以起到兩個作用:
降低系統組網復雜度。
降低編程復雜度,各個子系統不在是相互協商接口,各個子系統類似插口插在插座上,Kafka承擔高速數據總線的作用。
同時為發布和訂閱提供高吞吐量。據了解,Kafka每秒可以生產約25萬消息(50 MB),每秒處理55萬消息(110 MB)。
可進行持久化操作。將消息持久化到磁盤,因此可用于批量消費,例如ETL,以及實時應用程序。通過將數據持久化到硬盤以及replication防止數據丟失。
分布式系統,易于向外擴展。所有的producer、broker和consumer都會有多個,均為分布式的。無需停機即可擴展機器。
消息被處理的狀態是在consumer端維護,而不是由server端維護。當失敗時能自動平衡。
支持online和offline的場景。
如上圖所示,一個典型的Kafka集群中包含若干Producer(可以是web前端產生的Page View,或者是服務器日志,系統CPU、Memory等),若干broker(Kafka支持水平擴展,一般broker數量越多,集群吞吐率越高),若干Consumer Group,以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置,選舉leader,以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將消息發布到broker,Consumer使用pull模式從broker訂閱并消費消息。
1、吞吐量
高吞吐是kafka需要實現的核心目標之一,為此kafka做了以下一些設計:
數據磁盤持久化:消息不在內存中cache,直接寫入到磁盤,充分利用磁盤的順序讀寫性能
zero-copy:減少IO操作步驟
數據批量發送
數據壓縮
Topic劃分為多個partition,提高parallelism
producer根據用戶指定的算法,將消息發送到指定的partition
存在多個partiiton,每個partition有自己的replica,每個replica分布在不同的Broker節點上
多個partition需要選取出lead partition,lead partition負責讀寫,并由zookeeper負責fail over
通過zookeeper管理broker與consumer的動態加入與離開
拉取系統
由于kafka broker會持久化數據,broker沒有內存壓力,因此,consumer非常適合采取pull的方式消費數據,具有以下幾點好處:
簡化kafka設計
consumer根據消費能力自主控制消息拉取速度
consumer根據自身情況自主選擇消費模式,例如批量,重復消費,從尾端開始消費等
可擴展性
當需要增加broker結點時,新增的broker會向zookeeper注冊,而producer及consumer會根據注冊在zookeeper上的watcher感知這些變化,并及時作出調整。
Kafka的應用場景
1.消息隊列
比起大多數的消息系統來說,Kafka有更好的吞吐量,內置的分區,冗余及容錯性,這讓Kafka成為了一個很好的大規模消息處理應用的解決方案。消息系統一般吞吐量相對較低,但是需要更小的端到端延時,并嘗嘗依賴于Kafka提供的強大的持久性保障。在這個領域,Kafka足以媲美傳統消息系統,如ActiveMR或RabbitMQ。
2.行為跟蹤
Kafka的另一個應用場景是跟蹤用戶瀏覽頁面、搜索及其他行為,以發布-訂閱的模式實時記錄到對應的topic里。那么這些結果被訂閱者拿到后,就可以做進一步的實時處理,或實時監控,或放到Hadoop/離線數據倉庫里處理。
3.元信息監控
作為操作記錄的監控模塊來使用,即匯集記錄一些操作信息,可以理解為運維性質的數據監控吧。
4.日志收集
日志收集方面,其實開源產品有很多,包括Scribe、Apache Flume。很多人使用Kafka代替日志聚合(log aggregation)。日志聚合一般來說是從服務器上收集日志文件,然后放到一個集中的位置(文件服務器或HDFS)進行處理。然而Kafka忽略掉文件的細節,將其更清晰地抽象成一個個日志或事件的消息流。這就讓Kafka處理過程延遲更低,更容易支持多數據源和分布式數據處理。比起以日志為中心的系統比如Scribe或者Flume來說,Kafka提供同樣高效的性能和因為復制導致的更高的耐用性保證,以及更低的端到端延遲。
5.流處理
這個場景可能比較多,也很好理解。保存收集流數據,以提供之后對接的Storm或其他流式計算框架進行處理。很多用戶會將那些從原始topic來的數據進行階段性處理,匯總,擴充或者以其他的方式轉換到新的topic下再繼續后面的處理。例如一個文章推薦的處理流程,可能是先從RSS數據源中抓取文章的內容,然后將其丟入一個叫做“文章”的topic中;后續操作可能是需要對這個內容進行清理,比如回復正常數據或者刪除重復數據,最后再將內容匹配的結果返還給用戶。這就在一個獨立的topic之外,產生了一系列的實時數據處理的流程。Strom和Samza是非常著名的實現這種類型數據轉換的框架。
6.事件源
事件源是一種應用程序設計的方式,該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日志數據,這使得它成為一個對這種方式的應用來說絕佳的后臺。比如動態匯總(News feed)。
7.持久性日志(commit log)
Kafka可以為一種外部的持久性日志的分布式系統提供服務。這種日志可以在節點間備份數據,并為故障節點數據回復提供一種重新同步的機制。Kafka中日志壓縮功能為這種用法提供了條件。在這種用法中,Kafka類似于Apache BookKeeper項目。
上述就是小編為大家分享的kafka分析與單機使用記錄是怎樣的了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。