一. kafka 入門

1、基本概念

   　Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者規模的網站中的全部動做流數據.這種動做（網頁瀏覽，搜索和其餘用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素.

Kafka有以下特性：

• 經過O(1)的磁盤數據結構提供消息的持久化，這種結構對於即便數以TB的消息存儲也可以保持長時間的穩定性能。
• 高吞吐量[2]   ：即便是很是普通的硬件Kafka也能夠支持每秒數百萬[2]   的消息。
• 支持經過Kafka服務器和消費機集羣 來分區消息。
• 支持 Hadoop並行數據加載。

 kafka對消息保存時根據Topic進行歸類，發送消息者成爲Producer,消息接受者成爲Consumer,此外kafka集羣有多個kafka實例組成，每一個實例(server)成爲broker。不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

  術語：

• Broker
  Kafka集羣包含一個或多個服務器，這種服務器被稱爲broker[5]  
• Topic
  每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。（物理上不一樣Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處）。 一個Topic能夠認爲是一類消息，每一個topic將被分紅多個partition(區),每一個partition在存儲層面是append log文件。任何發佈到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset（偏移量），offset爲一個long型數字，它是惟一標記一條消息。kafka並無提供其餘額外的索引機制來存儲offset，由於在 kafka中幾乎不容許對消息進行「隨機讀寫」。
• Partition      Partition是物理上的概念，每一個Topic包含一個或多個Partition.      即便消息被消費,消息仍然不會被當即刪除.日誌文件將會根據broker中的配置要求,保留必定的時間以後刪除;好比log文件保留2天,那麼兩天後,文件會被清除,不管其中的消息是否被消費.kafka經過這種簡單的手段,來釋放磁盤空間,以及減小消息消費以後對文件內容改動的磁盤IO開支.        partitions的 設計目的有多個.最根本緣由是kafka基於文件存儲.經過分區,能夠將日誌內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每一個partiton都會被當前server(kafka實例)保存;能夠將一個topic切分多任意多個partitions,來消息保存/消費的效率.此外越多的partitions意味着能夠容納更多的consumer,有效提高併發消費的能力.(具體原理參見下文).
• Producer
  負責發佈消息到Kafka broker。  kafka集羣幾乎不須要維護任何consumer和producer狀態信息,這些信息有zookeeper保存;所以producer和consumer的 客戶端實現很是輕量級,它們能夠隨意離開,而不會對集羣形成額外的影響. Producer將消息發佈到指定的Topic中,同時Producer也能決定將此消息歸屬於哪一個partition;好比基於"round-robin"方式或者經過其餘的一些算法等.
• Consumer
  消息消費者，向Kafka broker讀取消息的客戶端。  對於consumer而言,它須要保存消費消息的offset,對於offset的保存和使用,有consumer來控制;當consumer正常消費消息時,offset將會"線性"的向前驅動,即消息將依次順序被消費.事實上consumer可使用任意順序消費消息,它只須要將offset重置爲任意值..(offset將會保存在zookeeper中,參見下文) 。本質上kafka只支持Topic. 每一個consumer屬於一個consumer group;反過來講, 每一個group中能夠有多個consumer.發送到Topic的消息,只 會被訂閱此Topic的每一個group中的一個consumer消費(同一個Group的多個consumer不會消費相同的message).
• Consumer Group
  每一個Consumer屬於一個特定的Consumer Group（可爲每一個Consumer指定group name，若不指定group name則屬於默認的group）。 若是全部的consumer都具備相同的group,這種狀況和queue模式很像;消息將會在consumers之間負載均衡. 若是全部的consumer都具備不一樣的group,那這就是"發佈-訂閱";消息將會廣播給全部的消費者.

      一個Topic的多個partitions,被分佈在kafka集羣中的多個server上;每一個server(kafka實例)負責partitions中消息的讀寫操做;此外kafka還能夠配置partitions須要備份的個數(replicas),每一個partition將會被備份到多臺機器上,以提升可用性.Kafka將每一個Topic進行分區Patition，以提升消息的並行處理，同時爲保證高可用性，每一個分區都有必定數量的副本 Replica，這樣當部分服務器不可用時副本所在服務器就能夠接替上來，保證系統可用性

      基於replicated方案,那麼就意味着須要對多個備份進行調度;每一個partition都有一個server爲"leader";leader負責全部的讀寫操做,若是leader失效,那麼將會有其餘follower來接管(成爲新的leader);follower只是單調的和leader跟進,同步消息便可..因而可知做爲leader的server承載了所有的請求壓力,所以從集羣的總體考慮,有多少個partitions就意味着有多少個"leader",kafka會將"leader"均衡的分散在每一個實例上,來確保總體的性能穩定.

        在kafka中,一個partition中的消息只會被group中的一個consumer消費;每一個group中consumer消息消費互相獨立;咱們能夠認爲一個group是一個"訂閱"者,一個Topic中的每一個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer能夠消費多個partitions中的消息.kafka只能保證一個partition中的消息被某個consumer消費時,消息是順序的.事實上,從Topic角度來講,消息仍不是有序的.

  kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,不然將意味着某些consumer將沒法獲得消息. 

    Guarantees

    1) 發送到partitions中的消息將會按照它接收的順序追加到日誌中

    2) 對於消費者而言,它們消費消息的順序和日誌中消息順序一致.

    3) 若是Topic的"replicationfactor"爲N,那麼容許N-1個kafka實例失效.

2、使用場景

   一、Messaging   

    對於一些常規的消息系統,kafka是個不錯的選擇;partitons/replication和容錯,可使kafka具備良好的擴展性和性能優點.不過到目前爲止,咱們應該很清楚認識到,kafka並無提供JMS中的"事務性""消息傳輸擔保(消息確認機制)""消息分組"等企業級特性;kafka只能使用做爲"常規"的消息系統, 在必定程度上,還沒有確保消息的發送與接收絕對可靠(好比,消息重發,消息發送丟失等)

    二、Websit activity tracking

    kafka能夠做爲"網站活性跟蹤"的最佳工具; 能夠將網頁/用戶操做等信息發送到kafka中.並實時監控,或者離線統計分析等

    三、Log Aggregation

    kafka的特性決定它很是適合做爲"日誌收集中心";application能夠將操做日誌"批量""異步"的發送到kafka集羣中,而不是保存在本地或者DB中;kafka能夠批量提交消息/壓縮消息等,這對producer端而言,幾乎感受不到性能的開支.此時consumer端可使hadoop等其餘系統化的存儲和分析系統.