kafka基本介紹

• kafka基礎知識

  • 幾個概念

  kafka做爲一個集羣運行在一個或多個服務器上。kafka集羣存儲的消息是以topic爲類別記錄的。每一個消息（也叫記錄record，我習慣叫消息）是由一個key，一個value和時間戳構成。

  不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

  kafka有四個核心API：

  • 應用程序使用 Producer API 發佈消息到1個或多個topic（主題）。
  • 應用程序使用 Consumer API 來訂閱一個或多個topic，並處理產生的消息。
  • 應用程序使用 Streams API 充當一個流處理器，從1個或多個topic消費輸入流，並生產一個輸出流到1個或多個輸出topic，有效地將輸入流轉換到輸出流。
  • Connector API容許構建或運行可重複使用的生產者或消費者，將topic鏈接到現有的應用程序或數據系統。例如，一個關係數據庫的鏈接器可捕獲每個變化。

  Client和Server之間的通信，是經過一條簡單、高性能而且和開發語言無關的TCP協議

  首先來了解一下Kafka所使用的基本術語：

  Topic

  • Kafka將消息種子(Feed)分門別類，每一類的消息稱之爲一個主題(Topic)

  Producer

  • 發佈消息的對象稱之爲主題生產者(Kafka topic producer)

  Consumer

  • 訂閱消息並處理髮布的消息的種子的對象稱之爲主題消費者(consumers)

  Broker

  • 已發佈的消息保存在一組服務器中，稱之爲Kafka集羣。集羣中的每個服務器都是一個代理(Broker). 消費者能夠訂閱一個或多個主題（topic），並從Broker拉數據，從而消費這些已發佈的消息。

  topic與log

  一個Topic能夠認爲是一類消息，每一個topic將被分紅多個partition(區),每一個partition在存儲層面是append log文件。任何發佈到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset（偏移量），offset爲一個long型數字，它是惟一標記一條消息。它惟一的標記一條消息。kafka並無提供其餘額外的索引機制來存儲offset，由於在kafka中幾乎不容許對消息進行「隨機讀寫」。每個分區都是一個順序的、不可變的消息隊列.
  

  Kafka集羣保持全部的消息，直到它們過時， 不管消息是否被消費了。日誌文件將會根據broker中的配置要求,保留必定的時間以後刪除, 實際上消費者所持有的僅有的元數據就是這個偏移量，也就是消費者在這個log中的位置。 這個偏移量由消費者控制：正常狀況當消費者消費消息的時候，偏移量也線性的的增長。可是實際偏移量由消費者控制，消費者能夠將偏移量重置爲更老的一個偏移量，從新讀取消息。 能夠看到這種設計對消費者來講操做自如， 一個消費者的操做不會影響其它消費者對此log的處理。

  partitions的設計目的有多個.最根本緣由是kafka基於文件存儲.經過分區,能夠將日誌內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每一個partiton都會被當前server(kafka實例)保存;能夠將一個topic切分多任意多個partitions,來消息保存/消費的效率.此外越多的partitions意味着能夠容納更多的consumer,有效提高併發消費的能力

  分佈式(Distribution)

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

  生產者(Producers)

  生產者往某個Topic上發佈消息。生產者也負責選擇發佈到Topic上的哪個分區。最簡單的方式從分區列表中輪流選擇。也能夠根據某種算法依照權重選擇分區。開發者負責如何選擇分區的算法。

  消費者(Consumers)

  一般來說，消息模型能夠分爲兩種， 隊列和發佈-訂閱式。

  • 隊列的處理方式是 一組消費者從服務器讀取消息，一條消息只有其中的一個消費者來處理。
  • 在發佈-訂閱模型中，消息被廣播給全部的消費者，接收到消息的消費者均可以處理此消息。

  消費者組

  • Kafka爲這兩種模型提供了單一的消費者抽象模型： 消費者組 （consumer group）。 消費者用一個消費者組名標記本身。 一個發佈在Topic上消息被分發給此消費者組中的一個消費者。
  • 假如全部的消費者都在一個組中，那麼這就變成了queue模型。
  • 假如全部的消費者都在不一樣的組中，那麼就徹底變成了發佈-訂閱模型

  更通用的， 咱們能夠建立一些消費者組做爲邏輯上的訂閱者。每一個組包含數目不等的消費者， 一個組內多個消費者能夠用來擴展性能和容錯。正以下圖所

  由於Topic分區中消息只能由消費者組中的惟一一個消費者處理,將意味着某些consumer將沒法獲得消息.

  Kafka採用了一種分而治之的策略：分區。 由於Topic分區中消息只能由消費者組中的惟一一個消費者處理 ，因此消息確定是按照前後順序進行處理的。可是它也僅僅是保證Topic的一個分區順序處理，不能保證跨分區的消息前後處理順序。

  因此，若是你想要順序的處理Topic的全部消息，那就只提供一個分區

  如上圖所示

  2個kafka集羣託管4個分區（P0-P3)
  2個消費者組，消費組A有2個消費者實例，消費組B有4個

  按照以上說法，同一個組中的消費者不能消費同一個分區

  kafka的保證

  1. 發送到partitions中的消息將會按照它接收的順序追加到日誌中
  2. 對於消費者而言,它們消費消息的順序和日誌中消息順序一致.
  3. 若是Topic的"replicationfactor"爲N,那麼容許N-1個kafka實例失效.

  kafka做爲一個存儲系統

  全部發布消息到消息隊列和消費分離的系統，實際上都充當了一個存儲系統（發佈的消息先存儲起來）。Kafka比別的系統的優點是它是一個很是高性能的存儲系統。寫入到kafka的數據將寫到磁盤並複製到集羣中保證容錯性。並容許生產者等待消息應答，直到消息徹底寫入。kafka的磁盤結構 - 不管你服務器上有50KB或50TB，執行是相同的。client來控制讀取數據的位置。你還能夠認爲kafka是一種專用於高性能，低延遲，提交日誌存儲，複製，和傳播特殊用途的分佈式文件系統。

  kafka使用場景

  • 消息
  • 指標
  • 日誌聚合
  • 流處理等