建站
咨詢
售后
建站咨詢
新聞中心
前言
Kafka 一開始是LinkedIn這家公司研發(fā)的技術(shù)，它是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，現(xiàn)在已成為大多數(shù)公司使用的技術(shù)，我們公司也不例外。那么你對kafka的了解有多少呢?那么本文就帶你過一過kafka中的一些關(guān)鍵要點。
站在用戶的角度思考問題，與客戶深入溝通，找到濉溪網(wǎng)站設(shè)計與濉溪網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋濉溪地區(qū)。
為什么我們需要Kafka？
訂單發(fā)生時通知其他服務(wù)
在我們深入研究之前，有必要重新審視一下 Kafka 最初被發(fā)明的原因。
想象一下為一家電子商務(wù)公司維護一組微服務(wù)。
下訂單時，訂單服務(wù)要通知很多服務(wù)，如下：
- 錢包服務(wù)從用戶賬戶中扣除金額
- 倉庫服務(wù)扣除物品的庫存數(shù)量
- 物流服務(wù)發(fā)貨
當訂單服務(wù)要通知更多的服務(wù)時，復雜度就要進一步提高。
訂單服務(wù)器需要做以下事情：
- 跟蹤都通知了誰
- 確保所有其他服務(wù)確實收到并處理
- 和其他服務(wù)建立直接的連接和處理不同的響應(yīng)
發(fā)現(xiàn)沒有，這很難擴展，如果接入更多的系統(tǒng)，訂單系統(tǒng)的開發(fā)天天996了。
因此，Kafka就很好的解決這樣的問題。
消息隊列與發(fā)布訂閱
訂單服務(wù)器只是將消息發(fā)布到 Pub-Sub/Message Queue
消息隊列和發(fā)布訂閱系統(tǒng)都是解決上述問題的關(guān)鍵。
也就是說，不是讓訂單服務(wù)維護直接和各種系統(tǒng)打交道，而是將事件發(fā)布或者推送到中間隊列中，對隊列感興趣的服務(wù)器（通常稱為消費者）訂閱隊列并相應(yīng)地消費事件。
那么消息隊列和發(fā)布訂閱系統(tǒng)有什么區(qū)別呢？
消息隊列
消息隊列是一種類似隊列的結(jié)構(gòu)，其中消息被發(fā)布并且僅被消費一次。這對于非冪等的進程很方便，事件應(yīng)該只由一個消費者處理，RabbitMQ 最初被設(shè)計成一個消息隊列。
發(fā)布-訂閱系統(tǒng)
另一方面，發(fā)布訂閱系統(tǒng)允許多個消費者多次使用一條消息。訂單事件被多個系統(tǒng)訂閱消費，所以更適合發(fā)布訂閱系統(tǒng)模式。Kafka 被設(shè)計為既是消息隊列又是發(fā)布訂閱系統(tǒng)。
Kafka組件
為了充分理解 Kafka 的工作原理，讓我們剖析 下Kafka 的各個組件。
Kafka Broker 和集群
Kafka 代理和集群
Kafka 只不過是一個管理數(shù)據(jù)發(fā)布和消費的服務(wù)。
一個Kafka Broker就是一個Kafka服務(wù)。維護同一組主題的一組Broker稱為 Kafka 集群。
發(fā)布者Publisher
發(fā)布者發(fā)布到 Kafka 代理
將數(shù)據(jù)發(fā)布到 Kafka Broker的服務(wù)稱為發(fā)布者。我們之前提到的Order服務(wù)是發(fā)布者的一個例子。
消費者Consumer
消費者從 Kafka 代理消費
另一方面，消費者是訂閱和消費來自 Kafka 主題的數(shù)據(jù)的服務(wù)。
在我們前面的示例中，Wallet服務(wù)器、Warehouse服務(wù)器和Logistic服務(wù)器充當Order主題的消費者。
主題Topic
Kafka 代理中的不同主題
Kafka 代理維護不同類型的事件，例如：
- 訂單創(chuàng)建事件
- 訂單取消事件
- 缺貨事件
這些事件中的每一個都是大量的數(shù)據(jù)流。主題只是一種事件或數(shù)據(jù)流。
發(fā)布到 Kafka 時，發(fā)布者指定消息應(yīng)發(fā)布到的主題。
主題是一個只能追加的日志。將消息附加到主題類似于將數(shù)據(jù)附加到隊列，它需要 O(1) 常數(shù)時間，因此速度非?？?。
分區(qū)Partition
主題被分片成分區(qū)
主題是存儲在 Kafka Broker上的追加的日志。
隨著消息數(shù)量的增加，Broker在特定主題上存儲的數(shù)據(jù)量是有限的，那怎么辦呢？
可以將一個主題拆分為多個分區(qū)，而不是將所有數(shù)據(jù)一直追加到同一個主體日志中，而是每個分區(qū)存儲特定主題的一部分數(shù)據(jù)，這類似于數(shù)據(jù)庫分片。
主題基于分區(qū)進行分片。同一主題的分區(qū)可以存儲在相同或不同的 Kafka Broker上。這使得 Kafka 具有高度可擴展性。
發(fā)布者在發(fā)布之前指定消息的主題和分區(qū)。因此，發(fā)布者有責任確保分區(qū)邏輯不會導致熱分區(qū)。
偏移量offset
分區(qū)中的偏移量
偏移量是分區(qū)中消息的唯一索引。
當 Kafka 將數(shù)據(jù)推送給消費者時，它會增加并跟蹤當前的偏移量。
有兩種類型的偏移量值得強調(diào)：
- 當前偏移量：保存在Consumer客戶端中，它表示Consumer希望收到的下一條消息的序號。
- 提交的偏移量： 保存在Broker上，它表示Consumer已經(jīng)確認消費過的消息的序號。
消費者組
如前所述，Kafka 既是消息隊列又是發(fā)布訂閱系統(tǒng)。這是通過消費者群體優(yōu)雅地設(shè)計的。
Consumer可以消費多個partition，但是每個partition只能被同組的一個consumer消費
消費者組由一組消費相同主題的消費者組成。
一個消費者一次可以消費多個分區(qū)。但是，每個分區(qū)只能由同一組中的一個且只有一個消費者使用。
一個分區(qū)可以被來自不同消費者組的多個消費者消費
消費者組是相互獨立的，不同的組可以同時使用同一主題并使用不同的偏移量。
通過將所有消費者放在同一組中來實現(xiàn)隊列，同一分區(qū)中的消息不會被來自相似組的不同消費者并發(fā)消費。
在分區(qū)級別實現(xiàn)隊列。因此，如果想要保證順序處理數(shù)據(jù)流，發(fā)布者必須確保數(shù)據(jù)始終被推送到同一個分區(qū)。
另一方面，發(fā)布訂閱系統(tǒng)是通過多個消費者組實現(xiàn)的。消費者群體彼此之間一無所知，并使用單獨的偏移量消費數(shù)據(jù)。
在前面的例子中，Wallet服務(wù)器和Logistic服務(wù)器分別屬于不同的消費者組，分別消費數(shù)據(jù)。
重新平衡和分區(qū)分配
當新消費者加入時，Kafka 會重新平衡
如果一組中只有一個消費者，則該消費者將負責消費所有可用分區(qū)。
當一個新的consumer加入group時，比如增加了一個新的server實例，Kafka會進行rebalancing，將一部分partitions分配給新的consumer。
這確保了每個消費者共享相同數(shù)量的工作，從而使 Kafka 具有可擴展性。
Kafka 使用自己的重新平衡策略進行分區(qū)重新分配，這值得另一篇單獨的文章來介紹。
復制Replica
副本在分區(qū)級別創(chuàng)建，可以存儲在相同/不同的代理中
單點故障是每個分布式系統(tǒng)的噩夢，Kafka也不例外。
如果Broker出現(xiàn)故障，存儲在代理上的分區(qū)可能不可用。因此，副本是在分區(qū)級別創(chuàng)建的。
為每個分區(qū)創(chuàng)建副本，并存儲在不同的 Kafka 代理上。為每個分區(qū)選舉一個領(lǐng)導者來為發(fā)布者和消費者服務(wù)。
副本不斷從leader同步數(shù)據(jù)。當 leader 宕機時，Zookeeper 會加入進來幫助進行 leader 的選舉。
Zookeeper
正如您可能正在思考的那樣，我們的難題中缺少一些部分。
- 我們?nèi)绾沃烂總€分區(qū)的領(lǐng)導者？
- 如何知道每個主題的分區(qū)數(shù)？
- 我們?nèi)绾沃烂總€消費者組的最新偏移量？
- 我們?nèi)绾沃烂總€消費者組中有多少消費者？
這就是Zookeeper發(fā)揮作用的地方。它是一個分布式協(xié)調(diào)服務(wù)系統(tǒng)，用于存儲元數(shù)據(jù)并協(xié)調(diào) Kafka 中的分布式系統(tǒng)。
主要涉及以下方面：
- 領(lǐng)導者選舉——確保每個分區(qū)都有一個領(lǐng)導者
- 集群成員資格——跟蹤集群中的所有功能代理
- 主題配置——跟蹤所有可用主題、分區(qū)及其副本
- 訪問控制列表——跟蹤每個組中消費者的數(shù)量及其訪問權(quán)限
- 配額——跟蹤每個客戶端可以讀取和寫入的數(shù)據(jù)量
長輪詢
Kafka 如何向消費者推送消息？
RabbitMQ 采用推送模型。代理與消費者保持持久的 TCP 連接，并在有可用數(shù)據(jù)時將數(shù)據(jù)推送給他們。
然而，推送模型可能會淹沒消費者。如果代理推送數(shù)據(jù)的速度快于消費者處理數(shù)據(jù)的速度，消費者可能會落后。RabbitMQ 確實有一個解決方案，這邊就不展開討論了。
長輪詢等待方式方法
Kafka 使用拉模型，也就是長輪詢。消費者定期從代理拉取數(shù)據(jù)。因此，消費者只有在準備好時才能拉取數(shù)據(jù)。但是，如果分區(qū)上沒有數(shù)據(jù)，來自消費者的定期輪詢可能會導致資源浪費。
Kafka通過使用“l(fā)ong polling”等待模式的方式解決了這個問題。簡而言之，如果分區(qū)上沒有數(shù)據(jù)，Kafka 不會返回空響應(yīng)。相反，broker保持連接并等待數(shù)據(jù)進入，然后再將其返回給消費者。
這減輕了當分區(qū)上沒有數(shù)據(jù)時消費者頻繁輪詢并防止資源浪費。
總結(jié)
本文總結(jié)了Kafka這個組件的基礎(chǔ)知識，希望讓大家對Kafka有一個宏觀的認識，感興趣的再深入分析底層的實現(xiàn)機制。
當前題目：關(guān)于Kafka，你需要知道的一切
分享路徑：http://www.dlmjj.cn/article/djpddsd.html
