1. 程式人生 > >高性能消息隊列 CKafka 核心原理介紹(上)

高性能消息隊列 CKafka 核心原理介紹(上)

幹貨 介紹 balance 拉取 這一 64bit 隱藏 2-2 kafka

歡迎大家前往騰訊雲技術社區,獲取更多騰訊海量技術實踐幹貨哦~

作者:閆燕飛

1.背景

Ckafka是基礎架構部開發的高性能、高可用消息中間件,其主要用於消息傳輸、網站活動追蹤、運營監控、日誌聚合、流式處理、事件追蹤、提交日誌等等需要高性能的場景,目前已經上線騰訊雲。Ckafka完全兼容現有的Kafka協議,使現有Kafka用戶可以零成本遷入Ckafka。Ckafka基於現有的Kafka進行了擴展開發和優化,為了方便用戶理解Ckafka本文也將對Kafka的實現原理進行較為詳細的介紹。

2.Kafka原理

2.1 Kafka誕生背景

Kafka是一種高吞吐量的采用發布訂閱模式的分布式消息系統,最初由LinkedIn采用Scala語言開發,用作LinkedIn的活動流追蹤和運營系統數據處理管道的基礎。現已成為Apache開源項目,其主要的設計目標如下:

  1. 以時間復雜度為O(1)的方式提供消息持久化能力,即使對TB級以上的數據也能保證常數時間復雜度的訪問性能。註:其實對於寫Kafka的確保證了O(1)的常數時間性能。但對於讀,是segment分片級別對數O(logn)時間復雜度。
  2. 高吞吐率。Kafka力爭即使在非常廉價的商用機上也能做到單機支持100Kqps的消息傳輸能力。
  3. 支持Kafka Server間的消息分區(partition),及分布式消費,同時保證每個partition內的消息順序傳輸。註:其實Kafka本身實現邏輯並不做該保證,主要的算法是集中在消費者端,由消費者的分配算法保證,詳情下面會介紹。
  4. 同時支持離線數據處理和實時數據處理。
  5. 支持在線水平擴展,Kafka的水平擴展主要來源於其分區(partition)的設計理念。

2.2 主流消息隊列對比

RabbitMQRocketMQCMQKafka
模式 發布訂閱 發布訂閱 傳統queue/發布訂閱 發布訂閱
同步算法 GM 同步雙寫 Raft ISR(Replica)
分布式擴展 支持 支持 支持
堆積能力 磁盤容量 磁盤容量 磁盤(水平擴展) 磁盤(水平擴展)
性能 很高
可靠性 一般 一般 極高 一般
持久化 內存/硬盤 磁盤 磁盤 磁盤

2.3 架構

2.3.1 整體架構圖

技術分享

2.3.2 相關概念介紹

2.3.2.1 zookeeper集群

Kafka系統強依賴的組件。其存儲了Kafka核心原數據 (如topic信息配置、broker信息、 消費分組等等,相當於DB充當了Kafka的配置管理中心) 。 Kafka的leader選舉(如coordinator選舉、controller選舉、partition leader選舉等等),同樣也會借助於zookeeper。

2.3.2.2 coordinator

coordinator協調器模塊,主要用來管理消費分組和消費offset,充當中介管理消費者並從消費分組中選舉出一個消費者作為leader,然後將消費分組中所有消費者信息發往該leader由該leader負責分配partition。該模塊為Kafka 0.9版本新加入的新的模塊,Kafka集群中可以存在多個協調器分別管不同的消費分組,提高整個系統的擴展能力,主要用於解決之前消費者(high level消費者api)都需要通過與zookeeper連接進行相關的選舉,導致zookeeper壓力大、驚群及腦裂問題。

2.3.2.3 controller

controller模塊,主要負責partition leader選舉、監聽創建及刪除Topic事件然後下發到指定broker進行處理等功能,整個Kafka集群中只能有一個controller,Kafka利用zookeeper的臨時節點特性來進行controller選舉。

2.3.2.4 Broker

消息緩存代理,Kafka集群包含一個或多個服務器,這些服務器被稱為Broker,負責消息的存儲於轉發,作為代理對外提供生產和消費服務。

2.3.2.5 Topic

消息主題(類別),邏輯上的概念,特指Kafka處理的消息源的不同分類,用戶可以根據自己的業務形態將不同業務類別的消息分別存儲到不同Topic。用戶生產和消費時只需指定所關註的topic即可,不用關註該topic的數據存放的具體位置。

2.3.2.6 Partition

Topic物理上的分組,在創建Topic時可以指定分區的數量,每個partition是一個有序的隊列,按生產順序存儲著每條消息,而且每條消息都會分配一個64bit的自增長的有序offset(相當於消息id)。Partition是整個Kafka可以平行擴展的關鍵因素。

2.3.2.7 Replication

副本,topic級別的配置,可以理解為topic消息的副本數。Kafka 0.8版本加入的概念,主要目的就是提高系統的可用性。防止broker意外崩潰導致部分partition不可以服務。

2.3.2.8 ISR

In-Sync Replicas ,Kafka用來維護跟上leader數據的broker列表,當leader崩潰後,優先從該列中選舉leader

2.3.2.9 Producer

Producer 生產者,采用Push方式進行消息發布生產。Producer可以通過與zookeeper連接獲取broker信息, topic信息等等元數據,然後再與broker交互進行消息發布。在此過程中zookeeper相當於一個配置管理中心(類似於Name Server提供相關的路由信息)。采用直接向Producer暴露zookeeper信息存在以下兩個非常大的弊端:

  1. zookeeper屬於整個Kafka系統的核心結構,其性能直接影響了整個集群的規模,故當暴露給生產者過多的生產者會導致zookeeper性能下降最終影響整個Kafka集群的規模和穩定性。
  2. zookeeper存儲著Kafka的核心數據,若公開暴露出去則容易受到惡意用戶的攻擊,最終導致Kafka集群不可服務,故非常不建議Kafka服務提供方向使用者暴露zookeeper信息。

正因為存在上面的問題,Kafka也提供了Metadata RPC,通過該RPC生產者可以獲取到broker信息、topic信息以及topic下partition的leader信息,然後生產者在訪問指定的broker進行消息生產,從而對生產者隱藏了zookeeper信息使的整個系統更加安全、穩定、高效。

2.3.2.10 Consumer

消費者,采用Pull方式,從Broker端拉取消息並進行處理。當采用訂閱方式(一般通過使用consumer high level api或new consumer來進行訂閱)訂閱感興趣的Topic時,Consumer必須屬於一個消費分組,而且Kafka保證同一個Topic的一條消息只能被同一個消費分組中的一個Consumer消費,但多個消費分組可以同時消費這一條消息。

其實Kafka本身不對這個(同一個topic的一條消息只能被同一個消費分組中一個消費者消費)做任何保證,尤其是在0.9版本之前Kafka Broker根本都沒有消費分組的概念也沒有消費offset概念,Kafka只是提供FetchMessage RPC供使用者去拉取消息,至於是誰來取,取多少次其根本不關心,該保證是由消費者api內部的算法自己完成。

在0.9版本之前消費分組只是消費者端的概念,同一個消費分組的所有消費者都通過與zookeeper連接註冊,然後自主選擇一個leader(一個消費分組一個leader),再通過該leader進行partition分配(分配算法默認是range,也可以配置成round robin甚至自己實現一個算法非常的靈活)。所有消費者都按照約定訪問分配給自己的partition,並且可以選擇將消費offset保持在zookeeper或自己存。該方式會暴露zookeeper從而導致存在和暴露zookeeper給Producer一樣的問題,並且因為任何一個消費者退出都會觸發zookeeper事件,然後重新進行rebalance,從而導致zookeeper壓力非常大、而且還存在驚群及無法解決的腦裂問題,針對這個問題0.9版本(含)之後,Kafka Broker添加了coordinator協調器模塊。

但coordinator模塊也未進行任何分配算法相關的處理,只是替換了zookeeper的一些功能,充當了中介將之前消費者都要通過zookeeper自己選擇leader, 變成統一和coordinator通信,然後由coordinator選擇leader,然後將同一個消費分組中的消費者都發送給leader(消費者api),由leader負責分配。另一個方面就是coordinator當前多了管理offset的功能,消費者可以選擇將offset提交給coordinator,然後由coordinator進行保存,當前默認情況下coordinator會將offset信息保存在一個特殊的topic(默認名稱_consumer_offsets)中,從而減少zookeeper的壓力。消費分組中partition的分配具體可以看下一個小結中消費分組的相關說明。

2.3.2.11 Consumer Group

消費分組,消費者標簽,用於將消費者分類。可以簡單的理解為隊列,當一個消費分組訂閱了一個topic則相當於為這個topic創建了一個隊列,當多個消費分組訂閱同一個topic則相當於創建多個隊列,也變相的達到了廣播的目的,而且該廣播只用存儲一份數據。 為了方便理解,通過下面的圖片對消費分組相關概念進行講解。

技術分享

  1. 一個消費分組可以訂閱多個topic,同理一個topic可以被多個消費分組訂閱
  2. topic中的partition只會分配給同一個消費分組中的一個消費者,基於這種分配策略,若在生產消息時采用按照消息key進行hash將同一個用戶的消息分配到同一partition則可以保證消息的先進先出。Kafka正是基於這種分配策略實現了消息的先進先出。
  3. 同一個消費分組中,不同的消費者訂閱的topic可能不一樣,但Kafka的partition分配策略保證在同一個消費分組的topic只會分配給訂閱了該topic的消費者,即消費分組中會按照topic再劃分一個維度。以上圖為例Consumer group1中C1和C2同時訂閱了Topic 1所以將Topic1下面的P0 ~ P3四個partition均分給C1和C2。同樣Consumer group1中只有C1訂閱了Topic0故Topic0中的兩個partition只分配給了C1未分配給C2。

2.3.2.12 Message

消息,是通信和存儲的最小單位。其包含一個變長頭部,一個變長key,和一個變長value。其中key和value是用戶自己指定,對用戶來說是不透明的。Message的詳細格式下面會有介紹,這裏先不展開說明。

下一篇:《高性能消息隊列 CKafka 核心原理介紹(下)》

相關閱讀

如何更優雅地使用 Redux

圖表組件常見設置

騰訊雲分布式高可靠消息隊列 CMQ 架構


此文已由作者授權騰訊雲技術社區發布,轉載請註明文章出處

原文鏈接:

此文已由作者授權騰訊雲技術社區發布,轉載請註明文章出處

原文鏈接:https://www.qcloud.com/community/article/549934

高性能消息隊列 CKafka 核心原理介紹(上)