【業務學習】初識Kafka

Grape

---

這幾天簡單學習了一下Kafka，看了一些書，也查了一些資料，結合這些，我簡單總結了一下Kafka的一些基礎知識,以此做記錄～
老規矩，拋出咱們這篇文章的三個問題：

1. 什麼是Kafka?
2. 有什麼優缺點？
3. 應用範圍是什麼？

你們簡單思考一下，若是你知道的話～

---

1.什麼是Kafka?

首先咱們看一下來自百度百科的定義：Kafka是由Apache軟件基金會開發的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者在網站中的全部動做流數據。
這裏邊有兩個重點：消息系統和發佈訂閱。那麼接下來咱們着重在這兩方面敘述。

消息系統

什麼是消息系統？簡單的說它主要是用來作數據收集處理以及傳輸的一個系統。數據工程中最具挑戰性的部分之一是如何從不一樣點收集和傳輸大量數據到分佈式系統進行處理和分析。須要經過消息隊列正確地分離大量數據，由於若是一部分數據沒法傳送，則能夠在系統恢復時傳輸和分析其餘數據。一般有兩種消息排隊：點對點(Point to point)和發佈者——訂閱者(publisher-subscriber)。 對於上述目的，它們都是可靠的和異步的。

發佈訂閱：

提及發佈訂閱咱們先來看下一般存在的兩種消息排隊中的另外一位玩家：點對點。在點對點或一對一中，有一個發件人和正在監聽發件人的多個消費者。當一個消費者從隊列收到消息時，該特定消息將從隊列中消失，而其餘消費者沒法得到該消息。
發佈訂閱：發佈者向同時收聽發佈者的多個消費者或訂閱者發送消息，而且每一個訂閱者能夠得到相同的消息。數據應經過數據管道傳輸，數據管道負責整合來自數據源的數據。
也就是說，點對點只能發送給一我的一份信息，而發佈訂閱式能夠發送給不用的人相同的信息。在這裏咱們不論述哪一種方式的好壞，由於，方式的好壞是看業務場景的。

明白了定義，咱們要知道Kafka的結構式什麼樣子的。大概就是如下圖示：

咱們看到，很明白的發佈訂閱者模式，以上三張圖也是由淺入深，第一張大概介紹整個Kafka架構，咱們能夠看到又多個發佈者向不一樣的broker發送消息，而後broker管理不一樣的topic，最後訂閱者去不一樣的分區消費消息。
固然，你可能還不太明白髮布者訂閱者之類的術語，下邊我來解答幾個常見的術語：
（1）Topics（主題） ：屬於特定類別的消息流稱爲主題。 數據存儲在主題中。Topic至關於Queue。主題被拆分紅分區。 每一個這樣的分區包含不可變有序序列的消息。分區被實現爲具備相等大小的一組分段文件。
（2）Partition（分區）

一個Topic能夠分紅多個Partition，這是爲了平行化處理。每一個Partition內部消息有序，其中每一個消息都有一個offset序號。一個Partition只對應一個Broker，一個Broker能夠管理多個Partition。
（3）Partition offset（分區偏移） 每一個分區消息具備稱爲 offset 的惟一序列標識。
（4）Replicas of partition（分區備份） 副本只是一個分區的備份。 副本從不讀取或寫入數據。 它們用於防止數據丟失。
（5）Brokers（經紀人）：單個的 Kafka 服務器叫作「中間人」（Broker）。一個 Kafka 中間人，接收生產者發來的消費，分配偏移量，並存儲入物理空間中去；同時，中間人還接收消費者的請求，把物理空間裏的消息響應回去。
（6）Kafka Cluster（Kafka集羣） Kafka有多個代理被稱爲Kafka集羣。 能夠擴展Kafka集羣，無需停機。 這些集羣用於管理消息數據的持久性和複製。
（7）Producers（生產者）： 生產者是發送給一個或多個Kafka主題的消息的發佈者。 生產者向Kafka經紀人發送數據。 每當生產者將消息發佈給代理時，代理只需將消息附加到最後一個段文件。實際上，該消息將被附加到分區。 生產者還能夠向他們選擇的分區發送消息。
（8）Consumers（消費者） ：Consumers從經紀人處讀取數據。 消費者訂閱一個或多個主題，並經過從代理中提取數據來使用已發佈的消息。

• Consumer本身維護消費到哪一個offset。
• 每一個Consumer都有對應的group。
• group內是queue消費模型：各個Consumer消費不一樣的 partition，所以一個消息在group內只消費一次。
• group間是publish-subscribe消費模型：各個group各自獨立消費，互不影響，所以一個消息被每一個group消費一次。
• 若是你對offset感興趣，推薦關於offset的一篇文章請看：Kafka Offset管理

到這咱們總結一下，發佈訂閱系統的大體流程就是生產者生產消息推送到brokers，各個broker將消息發送到不一樣的topic的分區上，而後再由消費者來進行消費（固然，這是最簡單的模式）。
注意：生產者也能夠向指定的某個topic由向他們選擇的分區發送消息。

2. 有什麼優缺點？

發佈/訂閱式的系統有不少，但Kafka出色在哪寫方面？

1. 解耦
   在項目啓動之初來預測未來項目會碰到什麼需求，是極其困難的。消息系統在處理過程當中間插入了一個隱含的、基於數據的接口層，兩邊的處理過程都要實現這一接口。這容許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵照一樣的接口約束。
2. 冗餘
   有些狀況下，處理數據的過程會失敗。除非數據被持久化，不然將形成丟失。消息隊列把數據進行持久化直到它們已經被徹底處理，經過這一方式規避了數據丟失風險。許多消息隊列所採用的」插入-獲取-刪除」範式中，在把一個消息從隊列中刪除以前，須要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。
3. 擴展性
   由於消息隊列解耦了你的處理過程，因此增大消息入隊和處理的頻率是很容易的，只要另外增長處理過程便可。不須要改變代碼、不須要調節參數。擴展就像調大電力按鈕同樣簡單。
4. 靈活性&峯值處理能力
   在訪問量劇增的狀況下，應用仍然須要繼續發揮做用，可是這樣的突發流量並不常見；若是爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列可以使關鍵組件頂住突發的訪問壓力，而不會由於突發的超負荷的請求而徹底崩潰。
5. 可恢復性
   系統的一部分組件失效時，不會影響到整個系統。消息隊列下降了進程間的耦合度，因此即便一個處理消息的進程掛掉，加入隊列中的消息仍然能夠在系統恢復後被處理。
6. 順序保證
   在大多使用場景下，數據處理的順序都很重要。大部分消息隊列原本就是排序的，而且能保證數據會按照特定的順序來處理。Kafka保證一個Partition內的消息的有序性。
7. 緩衝
   在任何重要的系統中，都會有須要不一樣的處理時間的元素。例如，加載一張圖片比應用過濾器花費更少的時間。消息隊列經過一個緩衝層來幫助任務最高效率的執行。寫入隊列的處理會盡量的快速。該緩衝有助於控制和優化數據流通過系統的速度。
8. 異步通訊
   不少時候，用戶不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，但並不當即處理它。想向隊列中放入多少消息就放多少，而後在須要的時候再去處理它們。
9. 持久化到磁盤
   Kafka實際上將全部記錄存儲到磁盤中，而且不會在RAM中保留任何內容。它保存在磁盤上的數據格式與從生產者發送過來或者發送給消費者的消息格式是同樣的。由於使用了相同的消息格式進行磁盤存儲和網絡傳輸，Kafka可使用零複製技術將消息直接發送給消費者，避免了對生產者已經壓縮過的消息進行解壓和再壓縮。

3. 應用範圍是什麼？

1. 活動跟蹤
   Kafka能夠記錄用戶訪問前端應用的活動日誌，這也是 LinkedIn 開發 Kafka 的初衷。Kafka蒐集的用戶點擊鼠標的事件、瀏覽頁面的事件、更改我的主頁的事件，都可以用做後端程序處理，使其變成有價值的產物。
2. 系統監控和日誌記錄
   能夠向 Kafka 中發送系統的運行日誌，經過分析這些日誌，能夠對系統的各個指標進行評估。同時，Kafka 記錄的日誌可供其它的日誌分析系統消費。
3. 發消息
   Kafka 能夠向其它應用發送中間件的消息，如：數據庫有改動，能夠將改動的信息發往應用程序。
4. 流式處理
   Kafka 提供的對數據的流式操做，和 Hadoop 的 Map/Reduce 模型相似，能夠作到數據的實時處理。
5. 等

參考文章：

• 初識 Kafka
• Kafka基本架構介紹
• 書籍：Kafka權威指南