《kafka權威指南》閱讀筆記——第1章 初識kafka

　　Kafka通常被稱爲「分佈式提交日誌」或者「分佈式流平臺」。文件系統或數據庫提交日誌用來提供全部事務的持久記錄，經過重放這些日誌能夠重建系統的狀態。一樣地，Kafka的數據是按照必定順序持久化保存的，能夠按需讀取。此外，Kafka的數據分佈在整個系統裏，具有數據故障保護和性能伸縮能力。

　　1.2.1　　消息和批次

　　Kafka的數據單元被稱爲消息。爲了提升效率，消息被分批次寫入Kafka。批次就是一組消息，這些消息屬於同一個主題和分區。若是每個消息都單獨穿行於網絡，會致使大量的網絡開銷，把消息分紅批次傳輸能夠減小網絡開銷。不過，這要在時間延遲和吞吐量之間作出權衡：批次越大，單位時間內處理的消息就越多，單個消息的傳輸時間就越長。

　　1.2.2　　模式

　　消息模式有許多可用的選項，像JSON和XML，易用可讀性好，但缺少強類型處理能力，版本間兼容性也不是很好。

　　數據格式的一致性對於Kafka來講很重要，它消除了消息讀寫操做之間的耦合性。若是讀寫操做緊密的耦合在一塊兒，消息訂閱者須要升級應用程序才能同時處理新舊兩種數據格式。在消息訂閱者升級了以後，消息發佈者才能跟着升級，以便使用新的數據格式。

　　1.2.3　　主題和分區

　　Kafka的消息經過主題進行分類。主題能夠被分爲若干個分區，一個分區就是一個提交日誌。消息以追加的方式寫入分區，而後以先入先出的順序讀取。要注意，因爲一個主題通常包含幾個分區，所以沒法在整個主題範圍內保證消息的順序，但能夠保證消息在單個分區內的順序。

　　Kafka經過分區來實現數據冗餘和伸縮性。分區能夠分佈在不一樣的服務器上，一個主題能夠橫跨多個服務器，以此來提供比單個服務器更強大的性能。

　　

　　流是一組從生產者移動到消費者的數據。

　　1.2.4　　生產者和消費者

　　Kafka的客戶端被分爲兩種基本類型：生產者和消費者。此外還有高級客戶端API，用於數據集成的Kafka Connect API和用於流式處理的Kafka Streams。

　　偏移量是一種元數據，它是一個遞增的整數值，保存在Zookeeper或Kafka上，消費者關閉或者重啓，讀取狀態不會丟失。

　　消費者是消費者羣組的一部分，也就是說，會有一個或者多個消費者共同讀取一個主題。羣組保證每一個分區只能被一個消費者使用，消費者與分區之間的映射一般被稱爲消費者對分區的全部權關係。經過這種方式，消費者能夠消費包含大量消息的主題。並且，若是一個消費者失效，羣組裏的其餘消費者能夠接管失效消費者的工做。

　　

　　1.2.5　　broker和集羣

　　一個獨立的Kafka服務器被稱爲broker。根據特定的硬件及其性能特徵，單個broker能夠輕鬆處理數千個分區以及每秒百萬級的消息量。

　　broker是集羣的組成部分。每一個集羣都有一個broker同時充當了集羣控制器的角色。控制器負責管理工做，包括將分區分配給broker和監控broker。在集羣中，一個分區從屬於一個broker，該broker被稱爲分區的首領。一個分區能夠分配給多個broker，這個時候會發生分區複製。這種複製機制爲分區提供了消息冗餘，若是一個broker失效，其餘broker能夠接管領導權。不過，相關的消費者和生產者都須要從新鏈接到新的首領。

　　

　　保留消息(在必定期限內)是Kafka的一個重要特性。Kafka broker默認的消息保留策略：要麼保留一段時間(好比7天)，要麼保留到消息達到必定大小的字節數(好比1GB)。當消息數量達到這些上限時，舊消息就會過時並刪除。主題能夠配置本身的保留策略，能夠將消息保留到再也不使用它們爲止。

　　1.2.6　　多集羣

 　　基於如下緣由，最好使用多個集羣。

• 　　數據類型分離
• 　　安全需求隔離
• 　　多數據中心(災難恢復)

　　Kafka的消息複製機制只能在單個集羣裏進行。Kafka提供了一個MirrorMaker的工具，能夠用來實現集羣間的消息複製。MirrorMaker的核心組件包含了一個生產者和一個消費者，二者經過一個隊列相連。

　　

　　

　　使用場景：1，活動跟蹤；2，傳遞消息；3，度量指標和日誌記錄；4，提交日誌；5，流處理