怎么解析分布式消息系統(tǒng)Kafka

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

10年積累的做網(wǎng)站、成都網(wǎng)站建設經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設流程，更有太倉免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

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

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

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

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

1、Kafka主要特點：

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

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

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

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

  5. 支持online和offline的場景。

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

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

3、幾個基本概念：

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

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

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

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

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

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

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

怎么解析分布式消息系統(tǒng)Kafka

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

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

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

5、Kafka的設計：

5.1 吞吐量

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

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

  2. zero-copy：減少IO操作步驟

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

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

  5. Topic劃分為多個partition，提高parallelism

5.2 負載均衡

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

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

  3. 多個partition需要選取出lead partition，lead partition負責讀寫，并由zookeeper負責fail over

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

5.3 拉取系統(tǒng)

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

  1. 簡化kafka設計

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

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

5.4 可擴展性

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

5.5 消息刪除策略

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

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

6、Kafka的應用場景：

6.1 消息隊列

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

6.2 行為跟蹤

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

6.3 元信息監(jiān)控

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

6.4 日志收集

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

6.5 流處理

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

6.6 事件源

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

6.7 持久性日志（commit log）

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

7、Kafka的設計要點：

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詳細的技術(shù)細節(jié)可以參考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/

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

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

7.4 顯式分布式。

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

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

文章標題：怎么解析分布式消息系統(tǒng)Kafka
地址分享：http://muchs.cn/article26/geppcg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站導航、定制網(wǎng)站、、網(wǎng)頁設計公司、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

成都做網(wǎng)站