Kafka（一）Kafka初識

1、基本概念

介紹

Kafka是一個分佈式的、可分區的、可複製的消息系統。它提供了普通消息系統的功能，但具備本身獨特的設計。這個獨特的設計是什麼樣的呢？
首先讓咱們看幾個基本的消息系統術語：

• Topic（主題）：kafka按照分類對信息源進行維護。實際工程中一個業務一個主題。
• Producers （生產者）：向kafka發佈消息的程序叫作生產者。
• Consumers（消費者）：從kafka的消息隊列中請求消息的客戶端應用程序叫作消費者。
• Broker（kafka實例）：kafka集羣中的一個實例叫作broker。

producers經過網絡將消息發送到Kafka集羣，集羣向消費者提供消息，以下圖所示：

服務端和客戶端的通訊是常見的tcp協議。Kafka支持多種語言的客戶端。

具體參考：https://cwiki.apache.org/confluence/display/KAFKA/Clients

Topics 和Logs

先來看一下Kafka提供的一個抽象概念:topic.
一個topic是對一組消息的概括。對每一個topic，Kafka 對它的日誌進行了分區，以下圖所示：

每一個分區都由一系列有序的、不可變的消息組成，這些消息被連續的追加到分區中。分區中的每一個消息都有一個連續的序列號叫作offset,用來在分區中惟一的標識這個消息。
在一個可配置的時間段內，Kafka集羣保留全部發布的消息，無論這些消息有沒有被消費。好比，若是消息的保存策略被設置爲2天，那麼在一個消息被髮布的 兩天時間內，它都是能夠被消費的。以後它將被丟棄以釋放空間。Kafka的性能是和數據量無關的常量級的，因此保留太多的數據並非問題。

實際上每一個consumer惟一須要維護的數據是消息在日誌中的位置，也就是offset.這個offset有consumer來維護：通常狀況下隨着 consumer不斷的讀取消息，這offset的值不斷增長，但其實consumer能夠以任意的順序讀取消息，好比它能夠將offset設置成爲一個 舊的值來重讀以前的消息。

以上特色的結合，使Kafka consumers很是的輕量級：它們能夠在不對集羣和其餘consumer形成影響的狀況下讀取消息。你可使用命令行來"tail"消息而不會對其餘正在消費消息的consumer形成影響。

將日誌分區能夠達到如下目的：首先這使得每一個日誌的數量不會太大，能夠在單個服務上保存。另外每一個分區能夠單獨發佈和消費，爲併發操做topic提供了一種可能。

分佈式

每一個分區在Kafka集羣的若干服務中都有副本，這樣這些持有副本的服務能夠共同處理數據和請求，副本數量是能夠配置的。副本使Kafka具有了容錯能力。
每一個分區都由一個服務器做爲「leader」，零或若干服務器做爲「followers」,leader負責處理消息的讀和寫，followers則去復 制leader.若是leader down了，followers中的一臺則會自動成爲leader。集羣中的每一個服務都會同時扮演兩個角色：做爲它所持有的一部分分區的leader，同 時做爲其餘分區的followers，這樣集羣就會據有較好的負載均衡。

Producers

Producer將消息發佈到它指定的topic中,並負責決定發佈到哪一個分區。一般簡單的由負載均衡機制隨機選擇分區，但也能夠經過特定的分區函數選擇分區。使用的更多的是第二種。

Consumers

發佈消息一般有兩種模式：隊列模式（queuing）和發佈-訂閱模式(publish-subscribe)。隊列模式中，consumers能夠同時 從服務端讀取消息，每一個消息只被其中一個consumer讀到；發佈-訂閱模式中消息被廣播到全部的consumer中。Consumers能夠加入一個 consumer 組，共同競爭一個topic，topic中的消息將被分發到組中的一個成員中。同一組中的consumer能夠在不一樣的程序中，也能夠在不一樣的機器上。如 果全部的consumer都在一個組中，這就成爲了傳統的隊列模式，在各consumer中實現負載均衡。若是全部的consumer都不在不一樣的組中， 這就成爲了發佈-訂閱模式，全部的消息都被分發到全部的consumer中。更常見的是，每一個topic都有若干數量的consumer組，每一個組都是一 個邏輯上的「訂閱者」，爲了容錯和更好的穩定性，每一個組由若干consumer組成。這其實就是一個發佈-訂閱模式，只不過訂閱者是個組而不是單個 consumer。

相比傳統的消息系統，Kafka能夠很好的保證有序性。
傳統的隊列在服務器上保存有序的消息，若是多個consumers同時從這個服務器消費消息，服務器就會以消息存儲的順序向 consumer分發消息。雖然服務器按順序發佈消息，可是消息是被異步的分發到各consumer上，因此當消息到達時可能已經失去了原來的順序，這意味着併發消費將致使順序錯亂。爲了不故障，這樣的消息系統一般使用「專用consumer」的概念，其實就是隻容許一個消費者消費消息，固然這就意味着失去了併發性。

在這方面Kafka作的更好，經過分區的概念，Kafka能夠在多個consumer組併發的狀況下提供較好的有序性和負載均衡。將每一個分區分只分發給一 個consumer組，這樣一個分區就只被這個組的一個consumer消費，就能夠順序的消費這個分區的消息。由於有多個分區，依然能夠在多個consumer組之間進行負載均衡。注意consumer組的數量不能多於分區的數量，也就是有多少分區就容許多少併發消費。

Kafka只能保證一個分區以內消息的有序性，在不一樣的分區之間是不能夠的，這已經能夠知足大部分應用的需求。若是須要topic中全部消息的有序性，那就只能讓這個topic只有一個分區，固然也就只有一個consumer組消費它。

ZooKeeper與Kafka

考慮一下有多個服務器的分佈式系統，每臺服務器都負責保存數據，在數據上執行操做。這樣的潛在例子包括分佈式搜索引擎、分佈式構建系統或者已知的系統如Apache Hadoop。 全部這些分佈式系統的一個常見問題是，你如何在任一時間點肯定哪些服務器活着而且在工做中。最重要的是，當面對這些分佈式計算的難題，例如網絡失敗、帶寬 限制、可變延遲鏈接、安全問題以及任何網絡環境，甚至跨多個數據中心時可能發生的錯誤時，你如何可靠地作這些事。這些正是Apache ZooKeeper所 關注的問題，它是一個快速、高可用、容錯、分佈式的協調服務。你可使用ZooKeeper構建可靠的、分佈式的數據結構，用於羣組成員、領導人選舉、協 同工做流和配置服務，以及廣義的分佈式數據結構如鎖、隊列、屏障（Barrier）和鎖存器（Latch）。許多知名且成功的項目依賴於 ZooKeeper，其中包括HBase、Hadoop 2.0、Solr Cloud、Neo4J、Apache Blur（Incubating）和Accumulo。

ZooKeeper是一個分佈式的、分層級的文件系統，能促進客戶端間的鬆耦合，並提供最終一致的，相似於傳統文件系統中文件和目錄的Znode視圖。它提供了基本的操做，例如建立、刪除和檢查Znode是否存在。它提供了事件驅動模型，客戶端能觀察特定Znode的變化，例如現有Znode增長了一個新的子節點。ZooKeeper運行多個ZooKeeper服務器，稱爲Ensemble，以得到高可用性。每一個服務器都持有分佈式文件系統的內存複本，爲客戶端的讀取請求提供服務。

上圖展現了典型的ZooKeeper ensemble，一臺服務器做爲Leader，其它做爲Follower。當Ensemble啓動時，先選出Leader，而後全部Follower復 制Leader的狀態。全部寫請求都經過Leader路由，變動會廣播給全部Follower。變動廣播被稱爲原子廣播。

Kafka中ZooKeeper的用途：正如ZooKeeper用於分佈式系統的協調和促進，Kafka使用 ZooKeeper也是基於相同的緣由。ZooKeeper用於管理、協調Kafka代理。每一個Kafka代理都經過ZooKeeper協調其它 Kafka代理。當Kafka系統中新增了代理或者某個代理故障失效時，ZooKeeper服務將通知生產者和消費者。生產者和消費者據此開始與其它代理 協調工做。Kafka總體系統架構以下圖所示。

參考地址

http://kafka.apache.org/documentation.html#introduction

http://www.infoq.com/cn/articles/apache-kafka/

http://www.aboutyun.com/thread-12882-1-1.html