概述

Kafka是分散式發布-訂閱消息系統。它最初由LinkedIn公司開發，之後成為Apache項目的一部分。Kafka是一個分散式的，可劃分的，冗餘備份的持久性的日誌服務。它主要用於處理活躍的流式數據。

在大數據系統中，常常會碰到一個問題，整個大數據是由各個子系統組成，數據需要在各個子系統中高性能，低延遲的不停流轉。傳統的企業消息系統並不是非常適合大規模的數據處理。為了已在同時搞定在線應用（消息）和離線應用（數據文件，日誌）Kafka就出現了。Kafka可以起到兩個作用：

降低系統組網複雜度。

降低編程複雜度，各個子系統不在是相互協商介面，各個子系統類似插口插在插座上，Kafka承擔高速數據匯流排的作用。

Kafka主要特點：

同時為發布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬消息（50 MB），每秒處理55萬消息（110 MB）。

可進行持久化操作。將消息持久化到磁碟，因此可用於批量消費，例如ETL，以及實時應用程序。通過將數據持久化到硬碟以及replication防止數據丟失。

分散式系統，易於向外擴展。所有的producer、broker和consumer都會有多個，均為分散式的。無需停機即可擴展機器。

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

支持online和offline的場景。

Kafka的架構：

kafka

Kafka的整體架構非常簡單，是顯式分散式架構，producer、broker（kafka）和consumer都可以有多個。Producer，consumer實現Kafka註冊的介面，數據從producer發送到broker，broker承擔一個中間緩存和分發的作用。broker分發註冊到系統中的consumer。broker的作用類似於緩存，即活躍的數據和離線處理系統之間的緩存。客戶端和伺服器端的通信，是基於簡單，高性能，且與編程語言無關的TCP協議。幾個基本概念：

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

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

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

Producers：消息和數據生產者，向Kafka的一個topic發布消息的過程叫做producers。

Consumers：消息和數據消費者，訂閱topics並處理其發布的消息的過程叫做consumers。

Broker：緩存代理，Kafa集群中的一台或多台伺服器統稱為broker。

消息發送的流程：

message

Producer根據指定的partition方法（round-robin、hash等），將消息發布到指定topic的partition裡面

kafka集群接收到Producer發過來的消息后，將其持久化到硬碟，並保留消息指定時長（可配置），而不關注消息是否被消費。

Consumer從kafka集群pull數據，並控制獲取消息的offset

一丶Kafka的設計：

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感知這些變化，並及時作出調整。

三丶Kayka的應用場景：

消息隊列

比起大多數的消息系統來說，Kafka有更好的吞吐量，內置的分區，冗餘及容錯性，這讓Kafka成為了一個很好的大規模消息處理應用的解決方案。消息系統一般吞吐量相對較低，但是需要更小的端到端延時，並嘗嘗依賴於Kafka提供的強大的持久性保障。在這個領域，Kafka足以媲美傳統消息系統，如ActiveMR或RabbitMQ。

行為跟蹤

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

元信息監控

作為操作記錄的監控模塊來使用，即彙集記錄一些操作信息，可以理解為運維性質的數據監控吧。

日誌收集

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

流處理

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

事件源

事件源是一種應用程序設計的方式，該方式的狀態轉移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日誌數據，這使得它成為一個對這種方式的應用來說絕佳的後台。比如動態匯總。

持久性日誌（commit log）

Kafka可以為一種外部的持久性日誌的分散式系統提供服務。這種日誌可以在節點間備份數據，並為故障節點數據回復提供一種重新同步的機制。Kafka中日誌壓縮功能為這種用法提供了條件。在這種用法中，Kafka類似於Apache BookKeeper項目。

四丶Kayka的設計要點：

直接使用linux 文件系統的cache，來高效緩存數據。

採用linux Zero-Copy提高發送性能。傳統的數據發送需要發送4次上下文切換，採用sendfile系統調用之後，數據直接在內核態交換，系統上下文切換減少為2次。根據測試結果，可以提高60%的數據發送性能。

數據在磁碟上存取代價為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。

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

總結

到這裡分散式消息應用系統：Kafka常用設計解析就結束了，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和大家交流幾點編程的經驗：

1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。

3丶 簡化演算法，代碼如惡魔，在你完成編碼后，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。

最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。

想了解學習以上內容可加群 569068099 加群驗證：（009）