分布式訊息系統：Kafka_分布式

Kafka是分布式發布-訂閱訊息系統。它最初由LinkedIn公司開發，之後成為Apache項目的一部分。Kafka是一個分布式的，可劃分的，冗餘備份的持久性的Log Service。它主要用於處理活躍的流式資料。

在大資料系統中，常常會碰到一個問題，整個大資料是由各個子系統組成，資料需要在各個子系統中高效能，低延遲的不停流轉。傳統的企業訊息系統並不是非常適合大規模的資料處理。為了已在同時搞定線上應用（訊息）和離線應用（資料檔案，日誌）Kafka就出現了。Kafka可以起到兩個作用： 降低系統組網複雜度。 降低編程複雜度，各個子系統不在是相互協商介面，各個子系統類似插口插在插座上，Kafka承擔高速資料匯流排的作用。 Kafka主要特點： 同時為發布和訂閱提供高輸送量。據瞭解，Kafka每秒可以生產約25萬訊息（50 MB），每秒處理55萬訊息（110 MB）。 可進行持久化操作。將訊息持久化到磁碟，因此可用於批量消費，例如ETL，以及即時應用程式。通過將資料持久化到硬碟以及replication防止資料丟失。 分布式系統，易於向外擴充。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴充機器。 訊息被處理的狀態是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。 支援online和offline的情境。 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。 訊息發送的流程：

  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的應用情境：

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/