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，流處理