Kafka學習分享|概念介紹
“截止今日Kafka學習分享的1.0版正式出爐，繼續迭代精進”
.1 什么是Kafka
Apache Kafka是一個開源的流處理平台，由 Apache Software Foundation使用Scala and Java編寫發展而來。Kafka™用於構建實時數據管道和流媒體應用。 它具有水平可擴展性，容錯性，快速性，並在數千家公司生產中運行。
它的主要功能：數據流的發布和訂閱、數據流的處理、數據流的存儲。像一個消息系統一樣發布和訂閱數據流，有效且實時地處理數據流，在一個分布式備份的集群中安全地處理存儲數據流。
.2 Kafka詳細介紹
.2.1 流處理平台的三個關鍵功能
l 它允許發布和訂閱可記錄的流。在這個方面，它類似於一個消息隊列或者一個企業消息系統。
l 它允許以一種容錯的方式存儲可記錄的流。
l 它允許當可記錄的流發生的時候來處理它們。
.2.2 Kafka的好處是什么？
它被用於兩類廣泛的應用程序：
l 構建能夠可靠地在系統和應用程序之間獲取數據的實時流數據管道。
l 構建對流數據轉換和響應的實時流應用程序。
.2.3 Kafka是如何運行的？
為了理解Kafka是怎樣做這些事情的，讓我們自下而上深入探索Kafka的能力。
一些概念
l Kafka作為一個集群在一個或多個服務器上運行；
l Kafka集群存儲可記錄的流的類別，稱為topics；
l 每條記錄包含一個key，一個value和一個timestamp；
Kafka有四個核心的APIs
l Producer API 允許一個應用程序將一條可記錄的流發布到一個或多個Kafka topics.
l Consumer API 允許一個應用程序訂閱一個或多個Kafka topics，並且處理生成給它們的可記錄流。
l Streams API允許一個應用程序扮演一個流處理器，消費來自一個或多個topics的輸入流並且生產輸出流給一個或多個topics，有效地將輸入流轉換成輸出流。
l Connector API允許構建和運行可復用的，將Kafka topics和現有應用程序或數據系統連接起來的生產者或消費者。如，一個相關數據的連機器可能捕獲一張表的每一個變化。
在Kafka中，客戶端和服務端之間的通信是由一個簡單的、高性能的、跨語言的TCP協議完成的。這種協議是版本控制的，並且與舊版本保持后向兼容。我們提供了一個Java客戶端給Kafka，但是客戶端支持多種語言。
Topics and Logs
一個Topic 就是記錄被發布的一個類別或者提要名稱，kafka用topic來標識存儲的一系列數據。每個topic可以有多個數據消費者和生產者，換句話說，一個topic可以有0個、一個、或多個訂閱了它的數據的消費者。
對於每一個topic，Kafka集群保持一個分區的log，如下圖：
每一個分區都是一個有序的，不變的可記錄的序列，這些序列不斷地添加到一個結構化的提交日志中。分區的記錄各自都被分配一個連續的ID號，被稱為偏移量，偏移量在分區中唯一標識每條記錄。
Kafka集群保留所有發布的記錄無論他們是否被消費，使用一個可配置的保留期。例如：如果保留策略設置為兩天，然后在一個記錄被發布后的兩天之內，它可以用於消費，之后它將被丟棄以釋放空間。Kafka可以存儲很長時間的數據且性能不受數據量大小的影響。“類似於MQ里面的queue，但是kafka的數據是持久化在磁盤上，在超時時間內，是可以反復按順序消費的。”
事實上，在每一個消費者基礎上保留的唯一的元數據是日志中消費者的偏移量或者位置。這個偏移量是由消費者控制的：通常，消費者會線性地提高它的偏移量來讀取記錄，但是，事實上，由於位置是由消費者控制的，消費者可以按照它想要的任何順序來消費記錄。例如，一個消費者可以重新設置為舊的偏移量，以重新處理過去的數據，或者跳到最近的記錄，並從“now”開始消費。“偏移量是記在ZooKeeper上，以消費者組為單位，路徑為/consumers/groupId/offsets/topicName/Partition；”
這種組合的特性意味着Kafka消費者是非常便宜的，他們的來去不會對集群或者其他的消費者產生一些影響。例如：你能夠使用我們的命令行工具來“tail”任何topic的內容，而不需要改變任何被現有消費者消費的內容。
日志中的分區有幾個目的。首先，他們允許日志擴展到超出一個適合單個服務器的大小。每個獨立的分區必須適合承載它的服務器，但是一個topic應該有許多的分區，因此它能夠處理任意數量的數據。其次，他們作為一個並行的單元，在這方面做的更多。
分布式
日志的分區分布在Kafka集群中不同的服務器上，每個服務器處理數據並請求共享分區。每個分區在一個可配置數量的服務器上進行復用，用於容錯。
每個分區有一個作為“leader”的服務器和0個或多個作為“followers”的服務器。主服務器處理該分區的所有讀寫請求，而從服務器被動地復制主服務器。如果主服務器出現故障，那么其他從服務器中的一個將自動成為新的主服務器。每個服務器充當某些分區的領導者，並為其他一些分區提供一個追隨者，因此在集群中負載均衡。
生產者
生產者發布它們選擇的數據給每個topics。生產者負責在topic中選擇哪條記錄分配到哪個分區上。這可以以循環的方式簡單實現負載均衡或者它可以根據一些語義分區函數（據說是根據記錄上的一些關鍵字）來完成。“具體的將數據發送到哪個分區下，由消費者決定，需要根據業務場景；沒有特殊要求的，可以隨機發送，盡可能的分攤到每個分區下，這樣對消費者那邊的多線程處理效率有比較大的提升；如果告警，最少需要將同一條告警的活躍和清除告警發送到同一個分區上。”
消費者
消費者給自己貼上一個消費者團體的標簽，每個被發布到一個topic的記錄都被交付到每個訂閱消費者團體中的一個消費者實例。消費者實例可以在單獨的進程中，也可以在單獨的機器上。“每個消費者都歸屬一個組，同一個組內的消費者，只能有一個消費者同時消費一個topic下某個分區下面的數據，換句話說，kafka的數據消費，是以topic的分區+消費者組為單位進行消費的。這樣的話，不同消費者組內的消費者可以同時消費同一個topic下同一個分區的數據。”
如果所有的消費者實例有相同的消費者團體，然后這些記錄將在這些消費者實例中有效地實現負載均衡。
如果所有的消費者實例有不同的消費者團體，然后每個記錄將被廣播到所有的消費者進程中。
一個兩個服務器的Kafka集群承載4個分區（P0-P3），其中有兩個消費者團體。消費者團體A有兩個消費者實例，並且消費者團體B有四個消費者實例。
然而，更常見的是，我們發現有少量消費者群體的topics，每個消費者都是“logical subscriber”。每個團體有許多用於可伸縮性和容錯的消費者實例組成。這只不過是，訂閱-發布語法，訂閱用戶是一組消費者而不是單個的進程。
在Kafka中實現消費的方式是將日志中的分區划分成多個消費者實例，因此，每個實例都是在任何時間點上“公平分享”分區的唯一的消費者。
團體中維護資格的進程由Kafka協議自由控制的。如果一個新的實例加入這個團體，他們將從其他團體成員中接管一些分區；如果一個實例死了，它的分區將被分配給其他剩余的實例。
Kafka只在一個分區內提供記錄的一個完整順序，而不是在一個topic內的不同分區之間。對於大多數應用程序來說，每個分區排序和按主鍵分區數據的能力都是足夠的。但是，如果你需要所有的記錄的一個完整的順序，這可以通過一個只有一個分區的topic實現，盡管這個將意味着每個消費者團體只有一個消費進程。
保障
一個高級別的Kafka將提供一下保障：
l 消息從一個生產者發送給一個特定的主題分區時將會附加上他們被發送的順序。也就是說，如果一條記錄M1和M2是有同一個生產者發送出去的，並且M1是先發送出去的，則M1的偏移量將會比M2的低，並且出現在log里更早。
l 一個消費者實例將按他們在log中存儲的順序來理解這些記錄。
l 對於一個具有備份元素N的topic，我們將容忍N-1服務器故障，而不會丟失任何記錄到日志中的記錄。
More details on these guarantees are given in the design section of the documentation.
.2.4 Kafka作為一個消息系統
Kafka消息系統與傳統企業消息系統的對比。
傳統消息有兩種模型：隊列和發布-訂閱（ queuing and publish-subscribe.）。
在對列中，一池的消費者將從一個服務上選讀，並且每條記錄都會被其中的一個消費者讀到；在發布-訂閱中，記錄將被廣播到所有的消費者。這兩種模型都有其優勢和劣勢。序列的優勢是它允許將數據處理進程分配給多個消費者實例，這樣可以讓你擴展你的進程。不幸的是，序列不是多用戶的，一旦一個進程讀取數據，數據就會消失。發布-訂閱，允許你廣播數據到多個進程，但是由於每條消失數據去了每個訂閱者，因此沒有辦法擴展進程。
Kafka中消費者團體的概念概括了這兩個概念。與隊列一樣，消費者組允許您通過一系列進程（消費者組的成員）來划分處理。與發布訂閱一樣，Kafka允許您將消息廣播到多個消費者組。
Kafka模型的優點是，每個主題都具有這兩個屬性 - 它可以擴展處理，也是多用戶 - 不需要選擇一個或另一個。
Kafka也比傳統的消息系統有更強的順序保證。
一個傳統的隊列在服務器上保留的消息記錄是按序的，如果多個用戶從該服務器消費消息，然后該服務器將按照消息存儲的順序分發消息。但是，盡管服務按序分發消息，這些消息是異步分發給消費者的，因此它們可能到達不同消息者的順序不同。這實際意味着消息的順序在並行消費的過程中丟失了。消息系統通常通過提供一個“獨有消費者”的概念來解決這個問題，獨有消費者允許一個進程從一個序列上消費，當然，這意味着進程處理過程中無並行性。
Kafka在這點上做得更好。通過在主題中各個分區有一個的並行概念，Kafka能夠同時提供順序保證和在一群消費者進行中實現負載均衡。這通過將一個TOPIC中的各個分區分配給一個消費者群體中的各個消費者來實現的，因此每一個分區只能被消費者群體的一個消費者消費掉。
通過這樣做我們確保這個消費者是這個分區的唯一的讀者並且消費按順序消費數據。由於這兒有許多分區，所以許多消費者實例之間仍然能夠實現負載均衡。注意：但是在一個消費者群體里消費者實例的個數不能超過分區數。
.1.1 Kafka流處理
僅僅讀、寫、存儲數據流是不夠的，真正的目的是能夠實現流數據的實時處理。
在Kafka中，一個流處理器是任何從輸入主題中獲取連續數據流的東西，在這個輸入上執行一些進程，並且生產連續的數據流給輸出主題。
例如，一個零售的應用程序可能會接收銷售和發貨的輸入流，並且輸出一連串的重新訂單和價格調整，計算這些數據。
它讓直接使用生產者和消費者的APIs進行簡單的處理成為可能。但是，對於更多復雜轉換，Kafka提供了一個完全集成流API。這允許建立重大的處理的應用程序，它從流中計算聚合或者加入流。
這個工具幫助解決了這類應用程序所面臨的難題：處理無序數據，處理輸入代碼更改，執行有狀態計算等等。
流API構建於Kafka提供的核心基礎之上：它使用生產者和消費者的API進行輸入，使用Kafka實現有狀態的存儲，並在流處理器實例中使用相同的群組機制來進行容錯。
.1.2 把分塊放在一起
消息、存儲和流處理的結合也許看起來不同尋常，但是這些對於Kafka作為一個流處理平台是必不可少的。
一個文件分發系統（像HDFS）允許存儲用於批處理的靜態文件。實際上一個系統像這樣允許從過去存儲和處理歷史的數據。
一個傳統企業消息系統允許處理未來的消息，這個將在你訂閱之后實現。按照這種方式建立的應用程序隨着未來數據的到來而處理它。
Kafka 將這些能力結合在一起，並且這個結合對於Kafka作為一個流處理應用程序和流數據管道是至關重要的。
通過結合存儲和低時延訂閱，流處理應用程序能夠用同樣的方式對待過去的和將來的數據。
那是一個單一的應用程序，能夠處理過去和未來的數據，而不是結束，當它到達最后的記錄時它可以繼續處理未來的數據。這是一個通用的流處理概念，它包含批處理和消息驅動的應用程序。
同樣的流數據管道訂閱實時事件的組合可以使用卡夫卡非常低延遲管道;但是可靠地存儲數據的能力使它可以使用它必須保證關鍵數據的數據或與離線系統的集成,數據加載只定期或長時間進行維護。流處理工具使在到達時轉換數據成為可能。
For more information on the guarantees, apis, and capabilities Kafka provides see the rest of the documentation.
PS：本文完全參考“https://kafka.apache.org/”，即kafka官方主頁。