Kafka-常用術語(消息、生產者、消費者、集群、broker解釋)
消息和批次
kafka的數據單元被稱為消息。類似於數據庫表中的一行數據。
消息由字節數組組成，所以對於kafka來說，消息里的數據沒有特別的格式或含義。
消息可以有一個可選的元數據，也就是鍵，鍵也是一個字節數組，當消息以一種可控的方式寫入不同的分區時，會用到鍵。最簡單的例子就是為鍵生成一個一致性散列值，然后使用散列值對主題分區數進行取模，為消息選取分區。這樣可以保證具有相同鍵的消息總是被寫到相同的分區上。
為了提高效率，消息被分批次寫入kafka。批次就是一組消息，這些消息屬於同一個主題和分區。
如果每一個消息都單獨穿行於網絡，會導致大量的網絡開銷，把消息分成批次傳輸可以減少網絡開銷。不過，這要在時間延遲和吞吐量之間做出權衡：批次越大，單位時間內處理的消息就越多，單個消息的傳輸時間就越長。批次數據會被壓縮，這樣可以提升數據的傳輸和存儲能力，但要做更多的計算處理。
模式
消息模式（schema）有很多的可用選項，如：JSON和XML，易用且可讀性好。但是有個缺點，缺乏強類型處理能力。不同版本之間的兼容性也不是很好。
Apache Avro，最初是為Hadoop開發的一款序列化框架。Avro提供了一種緊湊的序列化格式，模式和消息體是分開的，當模式發生變化時，不需要重新生成代碼；它還支持強類型和模式金花，版本向前向后都兼容。
數據格式的一致性對於kafka來說很重要，它消除了消息讀寫操作之間的耦合性。
主題和分區
Kafka的消息通過主題進行分類。主題好比數據庫的表，或者文件系統的文件夾。主題可以被分為若干個分區，一個分區就是一個提交日志。消息以追加的方式寫入分區，然后以先入先出的順序讀取。
注意：由於一個主題一般包括幾個分區，因此無法在整個主題范圍內保證消息的順序，但可以保證消息在單個分區內的順序。
kafka通過分區來實現數據冗余和伸縮性。分區可以分布在不同的服務器上，也就是說，一個主題可以橫跨多個服務器，以此來提供比單個服務器更強大的功能。
生產者和消費者
kafka的客戶端就是kafka系統的用戶，它們被分為兩種基本類型：生產者和消費者。除此之外，還有其他高級客戶端API--用於數據集成的kafka Connect API和用於流式處理的kafka Streams。
生產者創建消息。在其它發布與訂閱系統中，生產者可能被稱為發布者或寫入者。一般情況下，一個消息會被發布到一個特定的主題上。生產者在默認情況下把消息均衡地分布到主題的所有分區上，而並不關心特定消息會被寫到哪個分區。不過，在某些情況下，生產者會把消息直接寫到指定的分區。這通常是通過消息鍵和分區器來實現的，分區器為鍵生成一個散列值，並將其映射到指定的分區上。這樣可以保證包含同一個鍵的消息會被寫到同一個分區上。生產者也可以使用自定義的分區器，根據不同的業務規則將消息映射到分區。
消費者讀取消息。在其它發布與訂閱系統中，消費者可能被稱為訂閱者或者讀者。消費者訂閱一個或多個主題，並按照消息生成的順序讀取它們。消費者通過檢查消息的偏移量來區分已經讀取過的消息。
偏移量是另一種元數據，它是一個不斷遞增的整數值，在創建消息時，kafka會把它添加到消息里，在給定的分區里，每個消息的偏移量都是唯一的。消費者會把每個分區最后讀取的消息偏移量保存在zookeeper或kafka上，如果消費者關閉或重啟，它的讀取狀態不會丟失。
消費者是消費者群組的一部分，也就是說，會有一個或多個消費者共同讀取一個主題。群組保證每個分區只能被一個消費者使用。消費者與分區之間的映射通常被稱為消費者對分區的所有權關系。
通過這種方式，消費者可以消費包含大量消息的主題。而且，如果一個消費者失效，群組里的其它消費者可以接管失效消費者的工作。
broker和集群
一個獨立的kafka服務器被稱為broker。broker接收來自生產者的消息，為消息設置偏移量，並提交消息到磁盤保存。broker為消費者提供服務，對讀取分區的請求作出響應，返回已經提交到磁盤上的消息。根據特定的硬件及其性能特征，單個broker可以輕松地處理數千個分區以及每秒百萬級的消息量。
broker是集群的組成部分。每個集群都有一個broker同時充當了集群控制器的角色（自動從集群的活躍成員總選舉出來）。控制器負責管理工作：將分區分配給broker、監控broker。
在集群中，一個分區從屬於一個broker，該broker被稱為分區的首領。一個分區可以分配給多個broker，這個時候會發生分區的復制。這種復制機制為分區提供了消息冗余，如果有一個broker失效，其他broker可以接管領導權。不過，相關的消費者和生產者都要重新連接到新的首領。
保留消息(在一定期限內)是kafka的一個重要特性。Kafka broker默認的消息保留策略是這樣:要么保留一段時間（比如7天），要么保留消息達到一定大小的字節數（比如1GB）。當消息數量達到這些上限時，舊消息就會過期並被刪除，所以在任何時刻，可用消息的總量都不會超過配置參數所指定的大小。主題可以配置自己的保留策略，可以將消息保留到不再使用它們為止。
例如：用於跟蹤用戶活動的數據可能需要保留幾天，而應用程序的度量指標可能只需要保留幾個小時。可以通過配置把主題當作緊湊型日志，只有最后一個帶有特定鍵的消息會被保留下來。這種情況對於變更日志類型的數據來說比較適用，因為只關心最后時刻發生的那個變更。
多集群
隨着kafka部署數量的增加，基於以下幾點原因，最好使用多個集群
1.數據類型分離
2.安全需求隔離
3.多數據中心（災難恢復）
如果使用多個數據中心，就需要在它們之間復制消息。這樣，在線應用程序才可以訪問到多個站點的用戶活動信息。例如，如果一個用戶修改了他們的資料信息，不管從哪個數據中心都應該能看到這些改動。或者多個站點的監控數據可以被聚集到一個部署了分析程序和告警系統的中心位置。不過，kafka的消息復制機制只能在單個及群里進行，不能在多個集群之間進行。
kafka提供了一個叫做MirrorMarker的工具，可以用它來實現集群間的消息復制。MirrorMarker的核心組件包含了一個生產者和消費者，兩者之間通過一個隊列相連。消費者從一個集群讀取消息，生產者把消息發送到另一個集群上。
兩個本地集群的消息被聚集到一個聚合集群上，然后將該集群復制到其他數據中心。