初識kafka
Kafka 從何而來？我們為什麼要開發 Kafka ? Kafka 到底是什麼？
Kafka 最初是 Linkedln 的一個内部基礎設施系統。我們發現，雖然有很多資料庫和系統可以用來存儲資料，但在我們的架構裡，剛好缺一個可以幫助處理持續資料流的元件。在開發 Kafka 之前，我們實驗了各種現成的解決方案，從消息系統到日志聚合系統，再到 ETL工具，它們都無陸搞足我們的需求。最後 ，我們決定從頭開發一個系統。我們不想隻是開發一個能夠存儲資料的系統，比如傳統的關系型資料庫、鍵值存儲引擎、搜尋引擎或緩存系統，我們希望能夠把資料看成是持續變化和不斷增長的流，井基于這樣的想主主建構出一個資料系統 。 事實上，是一個資料架構。
kafka權威指南中寫到
我們認為 Kafka 是一個流平台：在這個平台上可以釋出和訂閱資料流，并把它們儲存起來、進行處理，這就是建構 Kafka 的初衷。以這種方式來看待資料确實與人們習慣的想陸有所不同，但它确實在建構應用和架構方面表現出了強大的抽象能力。 Kafka 經常會被拿來與現有的技術作比較：企業級消息系統、大資料系統（如 Hadoop）和資料內建或 ETL工具。這裡的每一項比較都有一定的道理，但也有失偏頗。Kafka 有點像消息系統，允許釋出和訂閱消息流。從這點來看，它類似于 ActiveMQ 、RabbitMQ 或 IBM 的 MQSeries 等産品。盡管看上去有些相似，但 Kafka 與這些傳統的消息系統仍然存在很多重要的不同點，這些差異使它完全不同于消息系統。首先，作為一個現代的分布式系統， Kafka 以叢集的方式運作，可以自由伸縮，處理公司的所有應用程式。 Kafka 叢集并不是一組獨立運作的 broker，而是一個可以靈活伸縮的中心平台，可以處理整個公司所有的資料流。其次， Kafka 可以按照你的要求存儲資料，儲存多久都可以 。作為資料連接配接層， Kafka 提供了資料傳遞保證 可複制、持久化，保留多長時間完全可以由你來決定。最後，流式處理将資料處理的層次提升到了新高度 。 消息系統隻會傳遞消息，而 Kafka 的流式處理能力讓你隻用很少的代碼就能夠動态地處理派生流和資料集。Kafka 的這些獨到之處足以讓你刮目相看，它不隻是“另一個消息隊列” 。
(在正式讨論Kafka之前，先來了解釋出與訂閱消息系統的概念，并認識這個系統的重要性。資料（消息）的發送者（釋出者）不會直接把消息發送給接收者，這是釋出與訂閱消息系統的一個特點。釋出者以某種方式對消息進行分類，接收者（訂閱者）訂閱它們，以便接收特定類型的消息。釋出與訂閱系統一般會有一個 broker，也就是釋出消息的中心點。)
Kafka 就是一款基于釋出與訂閱的梢息系統。它一般被稱為“分布式送出日志”或者“分布式流平台”。檔案系統或資料庫送出日志用來提供所有事務的持久記錄 ， 通過重放這些日志可以重建系統的狀态。同樣地， Kafka 的資料是按照一定順序持久化儲存的，可以按需讀取 。 此外， Kafka 的資料分布在整個系統裡，具備資料故障保護和性能伸縮能力。
消息和批次
Kafka 的資料單元被稱為 消息 。如果你在使用 Kafka 之前已經有資料庫使用經驗，那麼可以把消息看成是資料庫裡的一個“資料行”或一條“記錄”。消息由位元組數組組成，是以對于 Kafka 來說，消息裡的資料沒有特别的格式或含義。消息可以有一個可選的中繼資料 ，也就是鍵。鍵也是一個位元組數組，與消息一樣，對于 Kafka 來說也沒有特殊的含義。 當消息以一種可控的方式寫入不同的分區時，會用到鍵。最簡單的例子就是為鍵生成一個一緻性散列值，然後使用散列值對主題分區數進行取模，為消息選取分區。這樣可以保證具有相同鍵的消息總是被寫到相同的分區上。
為了提高效率，消息被分批次寫入 Kafka 。 批次就是一組消息，這些消息屬于同一個主題和分區。如果每一個消息都單獨穿行于網絡，會導緻大量的網絡開銷，把消息分成批次傳輸可以減少網絡開銷。不過，這要在時間延遲和吞吐量之間作出權衡：批次越大，機關時間内處理的消息就越多，單個消息的傳輸時間就越長。批次資料會被壓縮，這樣可以提升資料的傳輸和存儲能力，但要做更多的計算處理。
模式
對于 Kafka 來說，消息不過是晦澀難懂的位元組數組，是以有人建議用一些額外的結構來定義消息内容，讓它們更易于了解。根據應用程式的需求， 消息模式 （ schema）有許多可用的選項。像 JSON 和 XML 這些簡單的系統，不僅易用，而且可讀性好。不過，它們缺乏強類型處理能力，不同版本之間的相容性也不是很好。 Kafka 的許多開發者喜歡使用Apache Avro ， 它最初是為 Hadoop 開發的一款序列化架構。 Avro 提供了一種緊湊的序列化格式，模式和消息體是分開的，當模式發生變化時，不需要重新生成代碼 ； 它還支援強類型和模式進化，其版本既向前相容， 也向後相容。資料格式的一緻性對于 Kafka 來說很重要，它消除了消息讀寫操作之間的輯合性。 如果讀寫操作緊密地桐合在一起，消息訂閱者需要更新應用程式才能同時處理新舊兩種資料格式。在消息訂閱者更新了之後，消息釋出者才能跟着更新，以便使用新的資料格式。新的應用程式如果需要使用資料，就要與消息釋出者發生耦合，導緻開發者需要做很多繁雜的工作。
是以，定義良好的模式，并把它們存放在公共倉庫，可以友善我們了解 Kafka 的消息結構。
主題和分區
Kaflca 的消息通過主題進行分類。主題就好比資料庫的表，或者檔案系統裡的檔案夾。主題可以被分為若幹個分區 ， 一個分區就是一個送出日志。消息以追加的方式寫入分區，然後以先入先出的順序讀取（隊列）。要注意，由于一個主題一般包含幾個分區，是以無法在整個主題範圍内保證消息的順序，但可以保證消息在單個分區内的順序。 Kafka 通過分區來實作資料備援和伸縮性。分區可以分布在不同的伺服器上，也就是說， 一個主題可以橫跨多個伺服器，以此來提供比單個伺服器更強大的性能。
我們通常會使用流這個詞來描述 Kafka 這類系統的資料。很多時候 ， 人們把一個主題的資料看成一個流，不管它有多少個分區。流是一組從生産者移動到消費者的資料。當我們讨論流式處理時，一般都是這樣描述消息的。 kafka Streams 、 Apache Samza 和 Storm 這些架構以實時的方式處理消息，也就是所謂的流式處理。我們可以将流式處理與離線處理進行比較，比如 Hadoop 就是被設計用于在稍後某個時刻處理大量的資料。
生産者和消費者
Kafka 的用戶端就是 Kafka 系統的使用者，它們被分為兩種基本類型 ： 生産者和消費者。除此之外，還有其他進階用戶端 API－←用于資料內建的 Kafka Connect API 和用于流式處理的 Kafka Streams。這些進階用戶端 API 使用生産者和消費者作為内部元件，提供了進階的功能。
生産者建立消息。在其他釋出與訂閱系統中，生産者可能被稱為釋出者或寫入者。一般情況下，一個消息會被釋出到一個特定的主題上。生産者在預設情況下把消息均衡地分布到主題的所有分區上，而并不關心特定消息會被寫到哪個分區。不過，在某些情況下，生産者會把消息直接寫到指定的分區。這通常是通過消息鍵和分區器來實作的，分區器為鍵生成一個散列值，并将其映射到指定的分區上。這樣可以保證包含同一個鍵的消息會被寫到同一個分區上。生産者也可以使用自定義的分區器，根據不同的業務規則将消息映射到分區。
消費者讀取消息。在其他釋出與訂閱系統中，消費者可能被稱為訂閱者或讀者。 消費者訂閱一個或多個主題，并按照消息生成的順序讀取它們。消費者通過檢查消息的偏移盤來區分已經讀取過的消息。 偏移量是另一種中繼資料，它是一個不斷遞增的整數值，在建立消息時， Kafka 會把它添加到消息裡。在給定的分區裡，每個悄息的偏移量都是唯一的。消費者把每個分區最後讀取的悄息偏移量儲存在 Zookeeper 或 Kafka 上，如果悄費者關閉或重新開機，它的讀取狀态不會丢失。消費者是消費者群組的一部分，也就是說，會有一個或多個消費者共同讀取一個主題 。 群組保證每個分區隻能被一個消費者使用 。下圖 所示的群組中，有 3 個消費者同時讀取一個主題。其中的兩個消費者各自讀取一個分區，另外一個消費者讀取其他兩個分區。消費者與分區之間的映射通常被稱為悄費者對分區的所有權關系 。通過這種方式，消費者可以消費包含大量消息的主題。而且，如果一個消費者失效，群組
裡的其他消費者可以接管失效消費者的工作。
broker和叢集
一個獨立的 Kafka 伺服器被稱為 broker。 broker 接收來自 生産者的消息，為消息設定偏移量，并送出消息到磁盤儲存。 broker 為消費者提供服務，對讀取分區的請求作出響應，傳回已經送出到磁盤上的消息。根據特定的硬體及其性能特征，單個 broker 可以輕松處理數千個分區以及每秒百萬級的消息量。
broker 是叢集的組成部分。每個叢集都有一個 broker 同時充當了叢集控制器的角色（自動從叢集的活躍成員中選舉出來）。控制器負責管理工作，包括将分區配置設定給broker和監控broker。在叢集中，一個分區從屬于一個 broker, 該 broker 被稱為分區的首領 。一個分區可以配置設定給多個 broker，這個時候會發生分區複制（見下圖）。這種複制機制為分區提供了消息備援，如果有一個 broker 失效，其他 broker 可以接管上司權。不過，相關的消費者和生産者都要重新連接配接到新的首領。
多叢集
随着 Kafka 部署數量的增加，基于以下幾點原因，最好使用多個叢集。
1.資料類型分離
2.安全需求隔離
3.多資料中心（災難恢複）
如果使用多個資料中心，就需要在它們之間複制消息。這樣，線上應用程式才可以通路到多個站點的使用者活動資訊。例如，如果一個使用者修改了他們的資料資訊，不管從哪個資料中心都應該能看到這些改動。或者多個站點的監控資料可以被聚集到一個部署了分析程式和告警系統的中心位置。不過， Kafka 的消息複制機制隻能在單個叢集裡進行，不能在多個叢集之間進行。
Kafka 提供了一個叫作 MirrorMaker 的工具，可以用它來實作叢集間的消息複制。MirrorMaker 的核心元件包含了一個生産者和一個消費者，兩者之間通過一個隊列相連。消費者從一個叢集讀取消息，生産者把消息發送到另一個叢集上。圖 1-8 展示了一個使
用 MirrorMaker 的例子，兩個“本地”叢集的消息被聚集到一個“聚合”叢集上，然後将該叢集複制到其他資料中心。不過，這種方式在建立複雜的資料管道方面顯得有點力不從心。
多資料中心架構圖如下