資料為企業的發展提供動力。我們從資料中獲取資訊，對它們進行分析處理，然後生成更多的資料。每個應用程式都會產生資料， 包括日誌訊息、度量指標、使用者活動記錄、晌應訊息等。

釋出與訂閱訊息系統

先來了解發布與訂閱訊息系統的概念，。資料（訊息）的傳送者（釋出者）不會直接把訊息傳送給接收者，這是釋出與訂閱訊息系統的一個特點。釋出者以某種方式對訊息進行分類，接收者（訂閱者）訂閱它們，以便接收特定型別的訊息。
釋出與訂閱系統一般會有一個broker ，也就是釋出訊息的中心點。

如何開始
釋出與訂閱訊息系統的大部分應用場景都是從一個簡單的訊息佇列或一個程序間通道開始的。
例如，你的應用程式需要往別處傳送監控資訊，可以直接在你的應用程式和另一個可以在儀表盤上顯示度量指標的應用程式之間建立連線， 然後通過這個連線推送度量指標，如圖所示。
（即兩個應用之間的訊息傳遞）

這是剛接觸監控系統時簡單問題的應對方案。過了不久，你需要分析更民時間片段的度量指標，而此時的儀表盤程式滿足不了需求，於是，你啟動了一個新的服務來接收度盤指標。
該服務把度量指標儲存起來，然後進行分析。與此同時，｛爾修改了原來的應用程式，把度量指標同時傳送到兩個儀表盤系統上。
現在，你又多了3 個可以生成度量指標的應用程式，它們都與這兩個服務直接相連。而你的同事認為最好可以對這些服務進行輪詢以便獲得告警功能，於是你為每一個應用程式增加了一個伺服器，用於提供度量指標。
再過一陣子，有更多的應用程式出於各自的目的，都從這些伺服器獲取度主指標。這時的架構看起來就像圖所示的那樣，節點間的連線一團糟。

這時，技術債務開始凸顯出來，於是你決定償還掉一些。你建立了一個獨立的應用程式，用於接收來自其他應用程式的度量指標，井為其他系統提供了一個查詢伺服器。
這樣，之前架構的複雜度被降低到圖所示的那樣。那麼恭喜你，你已經建立了一個基於釋出與訂閱的訊息系統。

獨立的佇列系統
在你跟度量指標打得不可開交的時候，你的一個同事也正在跟日誌訊息奮戰。還有另一個同事正在跟蹤網站使用者的行為，為負責機器學習開發的同事提供資訊，同時為管理團隊生成報告。你和同事們使用相同的方式建立這些系統，解輯資訊的釋出者和訂閱者。圖所示的架構包含了3 個獨立的釋出與訂閱系統。

這種方式比直接使用點對點的連線（圖1-2 ） 要好得多，但這裡有太多重複的地方。你的公司因此要為資料佇列維護多個系統，每個系統又有各自的缺陷和不足。
此時，你真正需要的是一個單一的集中式系統，它可以用來發布通用型別的資料，其規模可以隨著公司業務的增長而增長。

Kafka 登場

Kafka 就是為了解決上述問題而設計的一款基於釋出與訂閱的訊息系統。它一般被稱為“分散式提交日誌”或者“分散式流平臺”。

訊息和批次
Kafka 的資料單元被稱為訊息，可以把訊息看成是資料庫裡的一個“資料行”或一條“ 記錄”。
為了提高效率，訊息被分批次寫入Kafka 。
批次就是一組訊息，這些訊息屬於同一個主題和分割槽。如果每一個訊息都單獨穿行於網路，會導致大量的網路開銷，把訊息分成批次傳輸可以減少網路開銷。

模式
對於Kafka 來說，訊息不過是晦澀難懂的位元組陣列，所以有人建議用一些額外的結構來定義訊息內容，讓它們更易於理解。
Kafka 的許多開發者喜歡使用Apache Avro ， 它最初是為Hadoop 開發的一款序列化框架。Avro 提供了一種緊湊的序列化格式，模式和訊息體是分開的，當模式發生變化時，不需要重新生成程式碼；它還支援強型別和模式進化，其版本既向前相容， 也向後相容。
資料格式的一致性對於Kafka來說很重要，它消除了訊息讀寫操作之間的耦合性。定義良好的模式，並把它們存放在公共倉庫，可以方便我們理解Kafka的訊息結構。第3章將詳細討論模式和序列化。

主題和分割槽
Kaflca 的訊息通過主題進行分類。主題就好比資料庫的表，或者檔案系統裡的資料夾。主題可以被分為若干個分割槽， 一個分割槽就是一個提交日誌。訊息以追加的方式寫入分割槽，然後以先入先出FIFO的順序讀取。
由於一個主題一般包含幾個分割槽，因此無撞在整個主題範圍內保證訊息的順序，但可以保證訊息在單個分割槽內的順序。

我們通常會使用流這個詞來描述Kaflca 這類系統的資料。很多時候， 人們把一個主題的資料看成一個流，不管它有多少個分割槽。

生產者和消費者
Kafka 的客戶端就是Kafka 系統的使用者，它們被分為兩種基本型別： 生產者和消費者。

生產者也稱為釋出者和寫入者，它負責建立訊息。生產者在預設情況下把訊息均衡地分佈到主題的所有分割槽上，而並不關心特定訊息會被寫到哪個分割槽。
不過，在某些情況下，生產者會把訊息直接寫到指定的分割槽。這通常是通過訊息鍵和分割槽器來實現的，分割槽器為鍵生成一個雜湊值，並將其對映到指定的分割槽上。

消費者也稱為訂閱者或者讀者，它負責讀取訊息。消費者訂閱一個或多個主題，並按照訊息生成的順序讀取它們。消費者通過檢查訊息的偏移量來區分已經讀取過的訊息。
偏移量是另一種元資料，它是一個不斷遞增的整數值，在建立訊息時， Kafka 會把它新增到訊息裡。在給定的分割槽裡，每個訊息的偏移量都是唯一的。消費者把每個分割槽最後讀取的訊息偏移量儲存在Zookeeper 或Kafka 上，如果消費者關閉或重啟，它的讀取狀態不會丟失。

消費者是消費者群組的一部分，也就是說，會有一個或多個消費者共同讀取一個主題。群組保證每個分割槽只能被一個消費者使用。如果一個消費者失效，群組裡的其他消費者可以接管失效消費者的工作。

broker和叢集
一個獨立的Kafka 伺服器被稱為broker。
broker 接收來自生產者的訊息，為訊息設定偏移量，並提交訊息到磁碟儲存。broker 為消費者提供服務，對讀取分割槽的請求作出響應，返回已經提交到磁碟上的訊息。
broker 是叢集的組成部分。每個叢集都有一個broker 同時充當了叢集控制器的角色（自動從叢集的活躍成員中選舉出來）。控制器負責管理工作，包括將分割槽分配給broker 和監控broker。
在叢集中，一個分割槽從屬於一個broker，該broker 被稱為分割槽的首領。一個分割槽可以分配給多個broker ，這個時候會發生分割槽複製。
這種複製機制為分割槽提供了訊息冗餘，如果有一個broker 失效，其他broker 可以接管領導權。不過，相關的消費者和生產者都要重新連線到新的首領。

Kafka broker保留訊息的策略是這樣的：
要麼保留一段時間（比如7 天），要麼保留到訊息達到一定大小的位元組數（比如lGB ）。當訊息數量達到這些上限時，舊訊息就會過期井被刪除，所以在任何時刻， 可用訊息的總量都不會超過配置引數所指定的大小。
主題可以配置自己的保留策略，可以將訊息保留到不再使用它們為止。例如，用於跟蹤使用者活動的資料可能需要保留幾天，而應
用程式的度量指標可能只需要保留幾個小時。可以通過配置把主題當作緊湊型日誌， 只有最後一個帶有特定鍵的訊息會被保留下來。這種情況對於變更日誌型別的資料來說比較適用，因為人們只關心最後時刻發生的那個變更。

多叢集
隨著Kafka 部署數量的增加，基於以下幾點原因，最好使用多個叢集。

• 資料型別分離
• 安全需求隔離
• 多資料中心（災難恢復）

如果使用多個數據中心，就需要在它們之間複製訊息。不過， Kafka 的訊息複製機制只能在單個叢集裡進行，不能在多個叢集之間進行。Kafka 提供了一個叫作Mirror Maker 的工具，可以用它來實現叢集間的訊息複製。
Mirror Maker 的核心元件包含了一個生產者和一個消費者，兩者之間通過一個佇列相連。

圖展示了一個使用MirrorMaker 的例子，兩個“本地”叢集的訊息被聚集到一個“聚合”叢集上，然後將該叢集複製到其他資料中心。不過，這種方式在建立複雜的資料管道方面顯得有點力不從心。具體細節，我們第7章再討論。

為什麼選擇Kafka

基於釋出與訂閱的訊息系統那麼多，為什麼Kafka 會是一個更好的選擇呢？

• 多個生產者
• 多個消費者
• 基於磁碟的資料儲存
• 伸縮性
• 高效能
• 資料生態系統

它在基礎設施的各個元件之間傳遞訊息，為所有客戶端提供一致的介面。當與提供訊息模式的系統整合時，生產者和消費者之間不再有緊密的禍合，也不需要在它們之間建立任何型別的直連。我們可以根據業務需要新增或移除元件．因為生產者不再關心誰在使用資料，也不關心有多少個消費者。