簡介
Kafka擅長於做什么？
它被用於兩大類應用：
- 在應用間構建實時的數據流通道
- 構建傳輸或處理數據流的實時流式應用
幾個概念：
- Kafka以集群模式運行在1或多台服務器上
- Kafka以topics的形式存儲數據流
- 每一個記錄包含一個key、一個value和一個timestamp
Kafka有4個核心API：
- Producer API：用於應用程序將數據流發送到一個或多個Kafka topics
- Consumer API：用於應用程序訂閱一個或多個topics並處理被發送到這些topics中的數據
- Streams API：允許應用程序作為流處理器，處理來自一個或多個topics的數據並將處理結果發送到一個或多個topics中，有效的將輸入流轉化為輸出流
- Connector API：用於構建和運行將Kafka topics和現有應用或數據系統連接的可重用的produers和consumers。例如，如鏈接到關系數據庫的連接器可能會捕獲某個表所有的變更
Kafka客戶端和服務端之間的通信是建立在簡單的、高效的、語言無關的TCP協議上的。此協議帶有版本且向后兼容。我們為Kafka提供了Java客戶端，但是客戶端可以使用多種語言。
Topics and Logs
Topic是發布記錄的類別。Kafka中的Topics一般是多訂閱者的，也就是一個Topic可以有0個或多個Consumer訂閱它的數據。
對於每個主題，Kafka會會維護一個如下所示的分區日志：
每個分區是一個有序的，以不可變的記錄順序追加的Commit Log。分區中的每個記錄都有一個連續的ID，稱為Offset，唯一標識分區內的記錄。
Kafka集群使用記錄保存時間的配置來保存所有已發布的記錄（無論他們是否被消費）。例如，配置策略為兩天，那么在一條記錄發布兩天內，這條記錄是可以被消費的，之后將被丟棄以騰出空間。Kafka的性能和數據量無關，所以存儲長時間的數據並不會成為問題。
實際上唯一需要保存的元數據是消費者的消費進度，即消費日志的偏移量（Offset）。這個Offset是由Consumer控制的：通常消費者會在讀取記錄時以線性方式提升Offset，但是事實上，由於Offset由Consumer控制，因此它可以以任何順序消費記錄。例如一個Consumer可以通過重置Offset來處理過去的數據或者跳過部分數據。
這個特征意味着Kafka的Consumer可以消費“過去”和“將來”的數據而不對集群和其他Consumer不造成太大的影響。例如，可以使用命令行工具tail來獲取Topic尾部的內容而不對已經在消費Consumer造成影響。
分區日志有幾個目的。第一，使服務器能承載日志的大小，每個分區的日志必須可以被保存在單個服務器上，但是一個Topic可以擁有多個分區，那么它可以處理任意大小的數據量。第二，它們作為並行度的單位（更多的是這點的考慮）。
Distribution
分區日志分布在集群中服務器中，每個服務器處理一部分分區的數據和請求。每個分區可以配置分布的服務器，以實現容錯。
每個分區擁有一個Leader節點，和零或多個Follower。Leader處理該分區所有的讀寫請求，Follower復制Leader數據。如果Leader節點宕機，將會有一個Follower節點自動的轉化為Leader。每個節點成為其部分分區的Leader，並成為剩余分區的Follower，這樣整個集群的負載將比較均衡。
Producers
Producer發送數據到它選擇的Topic。Producer負責決定將數據發送到Topic的那個分區上。這可以通過簡單的循環方式來平衡負載，或則可以根據某些語義來決定分區（例如基於數據中一些關鍵字）。
Consumers
Consumer使用一個group name來標識自己的身份，每條被發送到一個Topic的消息都將被分發到屬於同一個group的Consumer的一個實例中（group name相同的Consumer屬於一個組，一個Topic的一條消息會被這個組中的一個Consumer實例消費）。Consumer實例可以在單獨的進程中或者單獨的機器上。
如果所有的Consumer實例都是屬於一個group的，那么所有的消息將被均衡的分發給每個實例。
如果所有的Consumer都屬於不同的group，那么每條消息將被廣播給所有的Consumer。
（上圖）一個包含兩個Server的Kafka集群，擁有四個分區（P0-P3），有兩個Consumer group：Group A和Group B。Group有C1、C2兩個Consumer，GroupB有C3、C4、C5、C6四個Consumer。
更常見的是，Topic有少量的Consumer group，每一個都是“一個邏輯上的訂閱者”。每個group包含多個Consumer實例，為了可伸縮性和容錯性。這就是一個發布-訂閱模式，只是訂閱方是一個集群。
Kafka中消費的實現方式是“公平”的將分區分配給Consumer，每一個時刻分區都擁有它唯一的消費者。Consumer成員關系有Kafka程度動態維護。如果新的Consumer加入了分區，那么它會從這個分區其他的Consumer中分配走一部分分區；如果部分Consumer實例宕機，它的分區會被其他Consumer實例接管。
Kafka只保證同一個分區內記錄的順序，而不是同一個Topic的不同分區間數據的順序。每個分區順序結合按Key分配分區的能力，能滿足大多數程序的需求。如果需要全局的順序，可以使用只有一個分區的Topic，這意味着每個group只能有一個Consumer實例（因為一個分區同一時刻只能被一份Consumer消費——多加的Consumer只能用於容錯）。
Guarantees
Kafka高級API中提供一些能力：
被一個Producer發送到特定Topic分區的消息將按照他們的發送順序被添加到日志中。這意味着，如果M1、M2是被同一個Producer發送出來的，且M1先發送，那么M1擁有更小的Offset，在日志中的位置更靠前。
Consumer按照消息的存儲順序在日志文件中查找消息。
對於復制配置參數為N的Topic，我們能容忍N-1的服務器故障，而不會丟失已經Commit的數據。有關這些保證更詳細的信息，參見文檔的設計部分。
Kafka as a Messaging System
Kafka的流模式和傳統的消息系統有什么區別？
消息傳統上有兩種模式：隊列和發布-訂閱。在隊列中，一群Consumer從一個Server讀取數據，每條消息被其中一個Consumer讀取。在發布-訂閱中，消息被廣播給所有的Consumer。這兩種模式有各自的優缺點。隊列模式的優點是你可以在多個消費者實例上分配數據處理，從而允許你對程序進行“伸縮”。確定是隊列不是多用戶的，一旦消息被一個Consumer讀取就不會再給其他Consumer。發布訂閱模式允許廣播數據到多個Consumer，那么就沒辦法對單個Consumer進行伸縮。
Kafka的Consumer group包含兩個概念。與隊列一樣，消費組允許通過一些進程來划分處理（每個進程處理一部分）。與發布訂閱一樣，Kafka允許廣播消息到不同的Consumer group。
Kafka模式的優勢是每個Topic都擁有隊列和發布-訂閱兩種模式。
Kafka比傳統的消息系統有更強的順序保證。
傳統的消息系統在服務器上按順序保存消息，如果多個Consumer從隊列中消費消息，服務器按照存儲的順序輸出消息。然后服務器雖然按照順序輸出消息，但是消息將被異步的傳遞給Consumer，所以他們將以不確定的順序到達Consumer。這意味着在並行消費中將丟失消息順序。傳統消息系統通常采用“唯一消費者”的概念只讓一個Consumer進行消費，但這就丟失了並行處理的能力。
Kafka做的更好一些。通過提供分區的概念，Kafka能提供消費集群順序和負載的平衡。這是通過將分區分配個一個Consumer group中唯一的一個Consumer而實現的，一個分區只會被一個分組中的一個Consumer進行消費。通過這么實現，能讓一個Consumer消費一個分區並按照順序處理消息。因為存在多個分區，所有可以在多個Consumer實例上實現負載均衡。注意，一個分組內的Consumer實例數不能超過分區數。
Kafka as a Storage System
任何將發送消息和消費結構的消息隊列都有效的用作一個消息的存儲系統。不同的是Kafka是一個更好的存儲系統。
被寫入到Kafka的數據將被寫入磁盤並復制以保證容錯。Kafka允許Producer等待確定，以保證Producer可以確認消息被成功持久化並復制完成。
Kafka使用的存儲結構，使其提供相同的能力，無論是存儲50KB或者50TB持久化數據。
因為允許客戶端控制讀取的位置，可以將Kafka視為高性能，低延遲的日志存儲、復制、傳播的分布式系統。
Kafka for Stream Processing
僅僅是讀寫和存儲流數據是不夠的，Kafka的目標是對流失數據的實時處理。
在Kafka中，Stream Producer從輸入的Topic中讀取數據，執行一些操作，生成輸出流到輸出的Topic中。
例如，零售的應用程序將收到銷售和出貨的輸入流，並輸出根據該數據計算的重排序和價格調整后的數據流。
可以使用Producer和Consumer實現簡單的處理。對於更復雜的轉換，Kafka提供的完成的Stream API，允許構建將流中數據聚合或將流連接到一起的應用。
這用於解決以下的一些困難：處理無需的數據，執行有狀態的計算等。
Stream API基於Kafka的核心函數古劍：使用Producer和Consumer API用於輸入，使用Kafka作為有狀態的存儲，使用group機制來實現Stream處理器的容錯。
Putting the Pieces Together
消息、存儲和流處理這種組合看是不尋常，但是Kafka作為流式平台這是必須的。
類似HDFS的分布式文件系統存儲靜態的文件用於批處理。這種的系統允許存儲和處理歷史數據。
傳統的企業消息系統允許處理在你訂閱之后的未來的數據。以這種方式構建的應用程序在未來數據到達時進行處理。
Kafka組合這些能力，並且組合這些對Kafka作為流應用平台和流數據通道至關重要。
通過組合存儲和低延遲的訂閱，流應用程序能以相同的方式處理過去和未來的數據。一個單一的程序可以處理過去的歷史數據，並且不會在達到一個位置時停止，而是能繼續處理將來到達的數據。這是一個廣泛的流處理的概念，其中包含批處理和消息驅動的應用程序。
同樣，對於數據流通道，組合訂閱機制和實時事件使Kafka成為非常低延遲的管道；數據的存儲能力使其能和可能會進行停機維護的周期性處理數據的離線系統集成，或用於必須保證數據被確認交付的場景。流處理程序可以在數據到達后進行處理。
其他關閉Kafka提供的API、功能，參閱其他文檔。
------------------------------------------------------------------------------
下面是博主的公眾號，后續會發布和討論一系列分布式消息隊列相關的內容，歡迎關注。
