【🔒 Message Queue - Kafka】串流時代的超入門簡介

更新於 發佈於 閱讀時間約 3 分鐘
raw-image


訊息的即時傳遞已然成為現代社會的趨勢了, 而扮演中樞平台的系統架構功能也漸趨複雜完整, Kafka是一個事件流平台, 正好滿足串流時代之下的即時訊息傳遞架構, 因此我們有必要深入來學習這套事件流平台, 不論是自動化、金融交易、IOT、物流…皆離不開即時的需求, 所以就讓我們蹲好馬步來好好的學習一番吧!

關鍵功能有哪些?

  • 寫入及訂閱事件流。
  • 可靠的儲存事件流。
  • 處理即時或過去的事件流。
  • 分散式、可擴展、容錯、安全。

解決了什麼問題?

如同「【Message Queue】 井然有序的排隊機制 - 基本介紹」所介紹的, 我們看看下圖, 左邊的情境, 當客人越來越多時, 後面的客人都必須等待廚師做好餐點才能做其他事情, 而我們再來看看右邊的情境, 每個客人只要將菜單交給櫃台之後就能去做其他事情了, 而廚師們依據櫃台的菜單做菜, 直到餐點完成後客人依序取餐, 這樣的方式讓整個過程更有效率的運作, 客人寫菜單後自由活動, 廚師依單作業, 各自角色獨立耦合, 減少等待的時間耗費, 中間櫃台負責收跟送。

raw-image


而Kafka就是扮演著櫃台的角色, 擔任客人與廚師之間的橋樑, 讓彼此之間能夠更有效率的作業。

基礎架構與角色

raw-image


核心重點來了, 我們深入使用kafka之前先來鳥瞰一下整體的架構設計以及各個組件扮演的角色, 往後才能夠更快的理解細部功能的設計與用途。

生產者(Producer)與消費者(Consumer)

這兩個角色是Message Queue架構之下的基本角色, 總是要有人消費才會有生產, 生產者(producer)專注於生產訊息並丟往kafka, 而消費者(consumer)則負責消化這些訊息並根據訊息的內容處理任務。

事件(Event)與訊息(Message)

raw-image


通知兒子去買菜就是一個「事件」的起源, 買什麼菜則是「訊息」的內容,而中間的訊息傳遞橋樑可以是電話、留言紙條、Line訊息…, 有沒有覺得Message Queue的概念套到生活上就通了呢?

主題(Topics)與分區(Partition)

raw-image


主題(Topics)的部份我們可以理解為「新聞」, 分區(Partition)的部份則可以理解為「各個地區」, 透過主題(Topics)與分區(Partition)讓我們將資料分流到不同節點, 進而提高吞吐量(【資訊軟體知識】認識延遲、吞吐量、頻寬的差別)。

一個主題可以有多個分區, 每個分區依序紀錄生產者送過來的訊息, 關於分區的派送策略我們後續會另外撰寫一篇來進行詳細的介紹, 這邊我們僅需要知道主題(Topics)與分區(Partition)的基本概念即可。

代理器(Broker)與群集(Cluster)

raw-image


單台Kafka為一個代理器(Broker), 而群集(Cluster)裡面可以有多個Broker, 負責分配 partitions與監控Broker, 進而實現負載平衡、資料備份、故障轉移…等功能。

結語

這個篇章我們先帶到Kafka的基本元件概念即可, 否則一次塞太多知識也難以消化, 我們對於整體架構有一定的基本認識之後, 接下來將針對各個元件內容細部的拆解與說明。

留言
avatar-img
留言分享你的想法!
avatar-img
阿Han的沙龍
129會員
284內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
阿Han的沙龍的其他內容
2024/12/18
我們在「【🔒 Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有分享過如何透過docker來架設kafka, 那麼在產品化的階段, 我們可能會預先規劃主題(topic)要有多少個partitions…等的配置, 基於一鍵啟動懶人包的原則, 我們希望按
Thumbnail
2024/12/18
我們在「【🔒 Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有分享過如何透過docker來架設kafka, 那麼在產品化的階段, 我們可能會預先規劃主題(topic)要有多少個partitions…等的配置, 基於一鍵啟動懶人包的原則, 我們希望按
Thumbnail
2024/09/11
上集回顧「【🔒Message Queue - Kafka】Schema Registry EP.1 傳輸訊息的標準格式制定者 」, 我們在文章中有提到當Schema升級時, 會衍生一些問題, 那這些問題主要是Schema Registry會根據我們的相容性策略來驗證新版的Schema是否合法, 這
Thumbnail
2024/09/11
上集回顧「【🔒Message Queue - Kafka】Schema Registry EP.1 傳輸訊息的標準格式制定者 」, 我們在文章中有提到當Schema升級時, 會衍生一些問題, 那這些問題主要是Schema Registry會根據我們的相容性策略來驗證新版的Schema是否合法, 這
Thumbnail
2024/07/24
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
2024/07/24
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
看更多
你可能也想看
Thumbnail
「欸!這是在哪裡買的?求連結 🥺」 誰叫你太有品味,一發就讓大家跟著剁手手? 讓你回購再回購的生活好物,是時候該介紹出場了吧! 「開箱你的美好生活」現正召喚各路好物的開箱使者 🤩
Thumbnail
「欸!這是在哪裡買的?求連結 🥺」 誰叫你太有品味,一發就讓大家跟著剁手手? 讓你回購再回購的生活好物,是時候該介紹出場了吧! 「開箱你的美好生活」現正召喚各路好物的開箱使者 🤩
Thumbnail
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
在網路速度有限的情況下,依序記錄不斷產生的資訊,能統計使用者在頁面上操作了哪些功能。
Thumbnail
在網路速度有限的情況下,依序記錄不斷產生的資訊,能統計使用者在頁面上操作了哪些功能。
Thumbnail
KSQL引擎, 串流形式的SQL? 聽了應該霧煞煞吧! 想像一下傳統的SQL, 是不是一個指令一個動作, 每發送一個指令之後就必須等到查詢/寫入…動作皆完成之後才回應, 然而在Streaming的應用上這顯然不太可行, 每分每秒都有資料流入的情境下, 資料的狀態都在變化, 假設我們一個指令一個動作,
Thumbnail
KSQL引擎, 串流形式的SQL? 聽了應該霧煞煞吧! 想像一下傳統的SQL, 是不是一個指令一個動作, 每發送一個指令之後就必須等到查詢/寫入…動作皆完成之後才回應, 然而在Streaming的應用上這顯然不太可行, 每分每秒都有資料流入的情境下, 資料的狀態都在變化, 假設我們一個指令一個動作,
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
連接器故名思議就是兩個系統之間的橋樑, 而Kafka Connect正是扮演著這樣的角色, 如圖上, 我們可以透過Kafka Connect將SQL的資料導出到Kafka並導入到MySQL。 豐富的Plugin Confluent Hub提供了各式各樣的外掛套件, 包括了MongoDB、My
Thumbnail
連接器故名思議就是兩個系統之間的橋樑, 而Kafka Connect正是扮演著這樣的角色, 如圖上, 我們可以透過Kafka Connect將SQL的資料導出到Kafka並導入到MySQL。 豐富的Plugin Confluent Hub提供了各式各樣的外掛套件, 包括了MongoDB、My
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News