Kafka教程-名詞定義

什麼是 Kafka

Apache Kafka 是一個基於分佈式日誌提交機制設計的發佈訂閱系統。數據在 kafka 中持久化，用戶能夠隨時按需讀取。另外數據以分佈式的方式存儲，提升容

錯性，易於擴展。

Message 和 Batches

Kafka 中最基本的數據單元是消息 message，若是使用過數據庫，那麼能夠把 Kafka 中的消息理解成數據庫裏的一條行或者一條記錄。消息是由字符數組組成 的，kafka 並不關係它內部是什麼，索引消息的具體格式與 Kafka 無關。消息能夠有一個可選的 key，這個 key 也是個字符數組，與消息同樣，對於 kafka 也 是透明的。key 用來肯定消息寫入分區時，進入哪個分區。最簡單的處理方式，就是把 key 做爲 hash 串，擁有相同 key 的消息，確定會進入同一個分區。

爲了提升效率，Kafka 以批量的方式寫入。一個 batch 就是一組消息的集合，這一組的數據都會進入同一個 topic 和 partition（這個是根據 producer 的配置來 定的）。每個消息都進行一次網絡傳輸會很消耗性能，所以把消息收集到一塊兒，再同時處理就高效的多了。固然，這樣會引入更高的延遲以及吞吐量： batch 越大，同一時間處理的消息就越多。batch 一般都會進行壓縮，這樣在傳輸以及存儲的時候效率都更高一些。

Schemas

對於 Kafa 來講，消息自己是不透明的，這樣就能對消息定義更多容易理解的內容。根據我的的需求不一樣，消息也會有不一樣的 schema。好比 JSON 或者about 雲大數據雲技術學習分享平臺 XML 都是對人來講很容易閱讀的格式。而後他們在不一樣的模式版本中間缺少一些處理的魯棒性和可擴展性。一些 Kafka 的開發者也傾向於使用 Apache Avro（最開始是用來爲 Hadoop 作序列化的），提供了緊湊的序列化格式，在發生變化時，也不須要從新生成代碼，具備很強的數據類型和模式，具備很好的 向前擴展與向後兼容的能力。

Kafka 中數據是連續的，在數據在寫入到同時也可能被讀取消費，這樣數據的格式就很重要了。若是數據的格式發生變化，消費的應用也須要作出適當的調整。 若是事先定義好了數據存儲的格式，那麼讀取數據的時候就不須要作特殊的處理了。

Topics 和 Partitions

消息都是以主題 Topic 的方式組織在一塊兒，Topic 也能夠理解成傳統數據庫裏的表，或者文件系統裏的一個目錄。一個主題由 broker 上的一個或者多個 Partition 分區組成。在 Kafka 中數據是以 Log 的方式存儲，一個 partition 就是一個單獨的 Log。消息經過追加的方式寫入日誌文件，讀取的時候則是從頭開始 按照順序讀取。注意，一個主題一般都是由多個分區組成的，每一個分區內部保證消息的順序行，分區之間是不保證順序的。若是你想要 kafka 中的數據按照時 間的前後順序進行存儲，那麼能夠設置分區數爲 1。以下圖所示，一個主題由 4 個分區組成，數據都以追加的方式寫入這四個文件。分區的方式爲 Kafka 提供

了良好的擴展性，每一個分區均可以放在獨立的服務器上，這樣就至關於主題能夠在多個機器間水平擴展，相對於單獨的服務器，性能更好。

在 Kafka 這種數據系統中常常會提起 stream 流這個詞，一般流被認爲是一個主題中的數據，而忽略分區的概念。這就意味着數據流就是從 producer 到 consumer。在不少框架中，好比 kafka stream,apache samza,storm 在操做實時數據的時候，都是這樣理解數據流的。這種操做的模式跟離線系統處理數據的 方式不一樣，如 hadoop，是在某一個固定的時間處理一批的數據。

Producer 和 Consumer

Kafka 中主要有兩種使用者：Producer 和 consumer。

Producer 用來建立消息。在發佈訂閱系統中，他們也被叫作 Publisher 發佈者或 writer 寫做者。一般狀況下，消息都會進入特定的主題。默認狀況下，生產者 不關係消息到底進入哪一個分區，它會自動在多個分區間負載均衡。也有的時候，消息會進入特定的一個分區中。通常都是經過消息的 key 使用哈希的方式肯定 它進入哪個分區。這就意味着若是全部的消息都給定相同的 key，那麼他們最終會進入同一個分區。生產者也可使用自定義的分區器，這樣消息能夠進入 特定的分區。about 雲大數據雲技術學習分享平臺

Consumer 讀取消息。在發佈訂閱系統中，也叫作 subscriber 訂閱者或者 reader 閱讀者。消費者訂閱一個或者多個主題，而後按照順序讀取主題中的數據。消 費者須要記錄已經讀取到消息的位置，這個位置也被叫作 offset。每一個消息在給定的分區中只有惟一固定的 offset。經過存儲最後消費的 Offset，消費者應用 在重啓或者中止以後，還能夠繼續從以前的位置讀取。保存的機制能夠是 zookeeper,或者 kafka 本身。 消費者是以 consumer group 消費者組的方式工做，由一個或者多個消費者組成一個組，共同消費一個 topic。每一個分區在同一時間只能由 group 中的一個消費 者讀取，在下圖中，有一個由三個消費者組成的 grouop，有一個消費者讀取主題中的兩個分區，另外兩個分別讀取一個分區。某個消費者讀取某個分區，也 能夠叫作某個消費者是某個分區的擁有者。 在這種狀況下，消費者能夠經過水平擴展的方式同時讀取大量的消息。另外，若是一個消費者失敗了，那麼其餘的 group 成員會自動負載均衡讀取以前失敗的

消費者讀取的分區。

Brokers 和 Clusters

單獨的 kafka 服務器也叫作 broker，Broker 從生產者那裏獲取消息，分配 offset，而後提交存儲到磁盤年。他也會提供消費者，讓消費者讀取分區上的消息， 並把存儲的消息傳給消費者。依賴於一些精簡資源，單獨的 broker 也能夠輕鬆的支持每秒數千個分區和百萬級的消息。 Kafka 的 broker 支持集羣模式，在 Broker 組成的集羣中，有一個節點也被叫作控制器（是在活躍的節點中自動選擇的）。這個 controller 控制器負責管理整個 集羣的操做，包括分區的分配、失敗節點的檢測等。一個 partition 只能出如今一個 broker 節點上，而且這個 Broker 也被叫作分區的 leader。一個分區能夠分 配多個 Broker，這樣能夠作到多個機器之間備份的效果。這種多機備份在其中一個 broker 失敗的時候，能夠自動選舉出其餘的 broker 提供服務。然而， producer 和 consumer 都必須鏈接 leader 才能正常工做。about 雲大數據雲技術學習分享平臺 Kafka 的一個重要特性就是支持數據的過時刪除，數據能夠在 Broker 上保留一段時間。Kafka 的 broker 支持針對 topic 設置保存的機制，能夠按照大小配置也

能夠按照時間配置。一旦達到其中的一個限制，多是時間過時也多是大小超過配置的數值，那麼這部分的數據都會被清除掉。每一個 topic 均可以配置它自

己的過時配置，所以消息能夠按照業務的須要進行持久化保留。好比，一個數據追蹤分析的 topic 能夠保留幾天時間，一些應用的指標信息則只須要保存幾個

小時。topic 支持日誌數據的壓縮，這樣 kafka 僅僅會保留最後一條日誌生成的 key。這在修改日誌類型的時候會很是有用。

歡迎關注微信公衆號：程序猿微刊，更多技術文章持續更新中