Kafka是由LinkedIn開發的一個分佈式的消息系統,使用Scala編寫,它以可水平擴展和高吞吐率而被普遍使用。目前愈來愈多的開源分佈式處理系統如Storm,Spark,Flink都支持與Kafka集成。如今咱們的數據實時處理平臺也使用到了kafka。如今它已被多家不一樣類型的公司做爲多種類型的數據管道和消息系統使用。安全
上面咱們提到kafka是一個分佈式的消息系統。那爲何要在咱們的數據處理平臺中使用這樣的一個消息系統呢?消息系統能給咱們帶來什麼樣的好處呢?網絡
(1) 解耦分佈式
在項目啓動之初來預測未來項目會碰到什麼需求,是極其困難的。消息系統在處理過程當中間插入了一個隱含的、基於數據的接口層,兩邊的處理過程都要實現這一接口。這容許你獨立的擴展或修改兩邊的處理過程,只要確保它們遵照一樣的接口約束。性能
(2) 冗餘學習
有些狀況下,處理數據的過程會失敗。除非數據被持久化,不然將形成丟失。消息隊列把數據進行持久化直到它們已經被徹底處理,經過這一方式規避了數據丟失風險。許多消息隊列所採用的"插入-獲取-刪除"範式中,在把一個消息從隊列中刪除以前,須要你的處理系統明確的指出該消息已經被處理完畢,從而確保你的數據被安全的保存直到你使用完畢。測試
(3) 擴展性優化
由於消息隊列解耦了你的處理過程,因此增大消息入隊和處理的頻率是很容易的,只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。spa
(4) 靈活性 & 峯值處理能力線程
在訪問量劇增的狀況下,應用仍然須要繼續發揮做用,可是這樣的突發流量並不常見;若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住突發的訪問壓力,而不會由於突發的超負荷的請求而徹底崩潰。代理
(5) 順序保證
在大多使用場景下,數據處理的順序都很重要。大部分消息隊列原本就是排序的,而且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。
(6) 緩衝
在任何重要的系統中,都會有須要不一樣的處理時間的元素。例如,加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行———寫入隊列的處理會盡量的快速。該緩衝有助於控制和優化數據流通過系統的速度。
上面咱們知道咱們有必要在數據處理系統中使用一個消息系統,可是咱們爲何必定要選kafka呢?如今的消息系統可不僅有kafka,俗話說得好,貨比三家,咱們看一下kafka與其餘消息系統的區別。
LinkedIn團隊作了個實驗研究,對比Kafka與Apache ActiveMQ V5.4和RabbitMQ V2.4的性能。LinkedIn在兩臺Linux機器上運行他們的實驗,每臺機器的配置爲8核2GHz、16GB內存,6個磁盤使用RAID10。兩臺機器經過1GB網絡鏈接。一臺機器做爲代理,另外一臺做爲生產者或者消費者。
3.1 生產者測試
對每一個系統,運行一個生產者,總共發佈1000萬條消息,每條消息200字節。Kafka生產者以1和50批量方式發送消息。ActiveMQ和RabbitMQ彷佛沒有簡單的辦法來批量發送消息,LinkedIn假定它的批量值爲1。結果以下圖所示:
Kafka性能要好不少的主要緣由包括:
(1) Kafka不等待代理的確認,以代理能處理的最快速度發送消息。
(2)Kafka有更高效的存儲格式。平均而言,Kafka每條消息有9字節的開銷,而ActiveMQ有144字節。其緣由是JMS所需的沉重消息頭,以及維護各類索引結構的開銷。LinkedIn注意到ActiveMQ一個最忙的線程大部分時間都在存取B-Tree以維護消息元數據和狀態。
3.2 消費者測試
爲了作消費者測試,LinkedIn使用一個消費者獲取總共1000萬條消息。LinkedIn讓全部系統每次拉請求都預獲取大約相同數量的數據,最多1000條消息或者200KB。對ActiveMQ和RabbitMQ,LinkedIn設置消費者確認模型爲自動。結果以下圖所示:
Kafka性能要好不少的主要緣由包括:
(1) Kafka有更高效的存儲格式;在Kafka中,從代理傳輸到消費者的字節更少。
(2) ActiveMQ和RabbitMQ兩個容器中的代理必須維護每一個消息的傳輸狀態。LinkedIn團隊注意到其中一個ActiveMQ線程在測試過程當中,一直在將KahaDB頁寫入磁盤。與此相反,Kafka代理沒有磁盤寫入動做。最後,Kafka經過使用sendfile API下降了傳輸開銷。
因爲篇幅限制,小編在這裏就不作過多的介紹了,須要更多技術文檔的小夥伴,能夠轉發此文讓更多的人學習到,而且關注一下小編由於之後還會持續更新,最後後臺私信「資料」來獲取更多的資料吧~~