分佈式消息Kafka的原理、基礎架構、使用場景

一:Kafka簡介

Apache Kafka是分佈式發佈-訂閱消息系統,在 kafka官網上對 kafka 的定義:一個分佈式發佈-訂閱消息傳遞系統。 它最初由LinkedIn公司開發,Linkedin於2010年貢獻給了Apache基金會併成爲頂級開源項目。Kafka是一種快速、可擴展的、設計內在就是分佈式的,分區的和可複製的提交日誌服務。web

二:Kafka基本架構

它的架構包括如下組件:segmentfault

一、話題(Topic):是特定類型的消息流。消息是字節的有效負載(Payload),話題是消息的分類名或種子(Feed)名;緩存

二、生產者(Producer):是可以發佈消息到話題的任何對象;服務器

三、服務代理(Broker):已發佈的消息保存在一組服務器中,它們被稱爲代理(Broker)或Kafka集羣;架構

四、消費者(Consumer):能夠訂閱一個或多個話題,並從Broker拉數據,從而消費這些已發佈的消息;併發

上圖中能夠看出,生產者將數據發送到Broker代理,Broker代理有多個話題topic,消費者從Broker獲取數據。app

三:Kafka基本原理

咱們將消息的發佈(publish)稱做 producer,將消息的訂閱(subscribe)表述爲 consumer,將中間的存儲陣列稱做 broker(代理),這樣就能夠大體描繪出這樣一個場面:負載均衡

生產者將數據生產出來,交給 broker 進行存儲,消費者須要消費數據了,就從broker中去拿出數據來,而後完成一系列對數據的處理操做。框架

kafka 官方給出的圖:分佈式

多個 broker 協同合做,producer 和 consumer 部署在各個業務邏輯中被頻繁的調用,三者經過 zookeeper管理協調請求和轉發。這樣一個高性能的分佈式消息發佈訂閱系統就完成了。

圖上有個細節須要注意,producer 到 broker 的過程是 push,也就是有數據就推送到 broker,而 consumer 到 broker 的過程是 pull,是經過 consumer 主動去拉數據的,而不是 broker 把數據主懂發送到 consumer 端的。

四:Zookeeper在kafka的做用

(1)不管是kafka集羣,仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

(2)Kafka使用zookeeper做爲其分佈式協調框架,很好的將消息生產、消息存儲、消息消費的過程結合在一塊兒。

(3)同時藉助zookeeper,kafka可以生產者、消費者和broker在內的因此組件在無狀態的狀況下,創建起生產者和消費者的訂閱關係,並實現生產者與消費者的負載均衡。

五:Kafka的特性

1.高吞吐量、低延遲

kafka每秒能夠處理幾十萬條消息,它的延遲最低只有幾毫秒,每一個topic能夠分多個partition, consumer group 對partition進行consume操做。

2.可擴展性

kafka集羣支持熱擴展

3.持久性、可靠性

消息被持久化到本地磁盤,而且支持數據備份防止數據丟失

4.容錯性

容許集羣中節點失敗(若副本數量爲n,則容許n-1個節點失敗)

5.高併發

支持數千個客戶端同時讀寫

file

Kafka的使用場景:

1.日誌收集

一個公司能夠用Kafka能夠收集各類服務的log,經過kafka以統一接口服務的方式開放給各類consumer,例如hadoop、Hbase、Solr等。

2.消息系統

解耦和生產者和消費者、緩存消息等。

3.用戶活動跟蹤

Kafka常常被用來記錄web用戶或者app用戶的各類活動,如瀏覽網頁、搜索、點擊等活動,這些活動信息被各個服務器發佈到kafka的topic中,而後訂閱者經過訂閱這些topic來作實時的監控分析,或者裝載到hadoop、數據倉庫中作離線分析和挖掘。

4.運營指標

Kafka也常常用來記錄運營監控數據。包括收集各類分佈式應用的數據,生產各類操做的集中反饋,好比報警和報告。

5.流式處理

好比spark streaming和storm

六:ActiveMQ、Kafka、RabbitMQ消息系統的對比

相關文章
相關標籤/搜索