分布式消息系统:Kafka
Kafka是分布式發布-訂閱消息系統。它最初由LinkedIn公司開發,之后成為Apache項目的一部分。Kafka是一個分布式的,可劃分的,冗余備份的持久性的日志服務。它主要用于處理活躍的流式數據。
在大數據系統中,常常會碰到一個問題,整個大數據是由各個子系統組成,數據需要在各個子系統中高性能,低延遲的不停流轉。傳統的企業消息系統并不是非常適合大規模的數據處理。為了已在同時搞定在線應用(消息)和離線應用(數據文件,日志)Kafka就出現了。Kafka可以起到兩個作用:
Kafka主要特點:
Kafka的架構:
?
Kafka的整體架構非常簡單,是顯式分布式架構,producer、broker(kafka)和consumer都可以有多個。Producer,consumer實現Kafka注冊的接口,數據從producer發送到broker,broker承擔一個中間緩存和分發的作用。broker分發注冊到系統中的consumer。broker的作用類似于緩存,即活躍的數據和離線處理系統之間的緩存。客戶端和服務器端的通信,是基于簡單,高性能,且與編程語言無關的TCP協議。幾個基本概念:
消息發送的流程:
?
Kafka的設計:
1、吞吐量
高吞吐是kafka需要實現的核心目標之一,為此kafka做了以下一些設計:
負載均衡
拉取系統
由于kafka broker會持久化數據,broker沒有內存壓力,因此,consumer非常適合采取pull的方式消費數據,具有以下幾點好處:
可擴展性
當需要增加broker結點時,新增的broker會向zookeeper注冊,而producer及consumer會根據注冊在zookeeper上的watcher感知這些變化,并及時作出調整。
Kayka的應用場景:
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項目。
Kayka的設計要點:
1、直接使用linux 文件系統的cache,來高效緩存數據。
2、采用linux Zero-Copy提高發送性能。傳統的數據發送需要發送4次上下文切換,采用sendfile系統調用之后,數據直接在內核態交換,系統上下文切換減少為2次。根據測試結果,可以提高60%的數據發送性能。Zero-Copy詳細的技術細節可以參考:https://www.ibm.com/developerworks/linux/library/j-zerocopy/
3、數據在磁盤上存取代價為O(1)。kafka以topic來進行消息管理,每個topic包含多個part(ition),每個part對應一個邏輯log,有多個segment組成。每個segment中存儲多條消息(見下圖),消息id由其邏輯位置決定,即從消息id可直接定位到消息的存儲位置,避免id到位置的額外映射。每個part在內存中對應一個index,記錄每個segment中的第一條消息偏移。發布者發到某個topic的消息會被均勻的分布到多個part上(隨機或根據用戶指定的回調函數進行分布),broker收到發布消息往對應part的最后一個segment上添加該消息,當某個segment上的消息條數達到配置值或消息發布時間超過閾值時,segment上的消息會被flush到磁盤,只有flush到磁盤上的消息訂閱者才能訂閱到,segment達到一定的大小后將不會再往該segment寫數據,broker會創建新的segment。
4、顯式分布式,即所有的producer、broker和consumer都會有多個,均為分布式的。Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行注冊,且zookeeper會保存他們的一些元數據信息。如果某個broker和consumer發生了變化,所有其他的broker和consumer都會得到通知。
參考資料:
- Apache Kafka網站
- 項目設計討論
- Github鏡像
- Morten Kjetland對Apache Kafka的介紹
- Quora上與RabbitMQ的對比
- Kafka: a Distributed Messaging System for Log Processing
- Zero-copy原理
- Kafka與Hadoop
from:?http://blog.jobbole.com/75328/
總結
以上是生活随笔為你收集整理的分布式消息系统:Kafka的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: java提高篇(九)-----实现多重继
- 下一篇: InnoDB 存储引擎体系架构