組成架構(gòu)

云消息隊(duì)列 Confluent 版是一個(gè)流數(shù)據(jù)平臺(tái)，能夠組織管理來自不同數(shù)據(jù)源的數(shù)據(jù)，是一個(gè)穩(wěn)定高效的系統(tǒng)。如下圖所示，它由六個(gè)組件構(gòu)成，分別為Kafka Broker、Rest Proxy、Connect、Zookeeper、ksqlDB、Control Center。

集群資源評(píng)估

Kafka Broker資源評(píng)估

• 首先，需要評(píng)估您的業(yè)務(wù)需求，需求參數(shù)由下表列出。

  需求參數(shù)	參數(shù)說明
  扇出因子	寫入的數(shù)據(jù)會(huì)被consumer消費(fèi)多少次，其中不包含Broker內(nèi)部副本的復(fù)制流量。
  數(shù)據(jù)峰值流入	業(yè)務(wù)數(shù)據(jù)的峰值流量，單位：MB/s。
  數(shù)據(jù)平均流入	業(yè)務(wù)數(shù)據(jù)的平均流量，單位：MB/s。
  數(shù)據(jù)保留時(shí)長	數(shù)據(jù)保留時(shí)長，默認(rèn)7天。
  分區(qū)副本因子	分區(qū)副本因子，默認(rèn)為3，即每個(gè)分區(qū)具有3個(gè)副本。

• 估算Broker的節(jié)點(diǎn)數(shù)：理想情況下，單個(gè)Kafka Broker最大能夠支持100 MB/s的流量；建議生產(chǎn)集群至少需要4個(gè)Broker節(jié)點(diǎn)數(shù)，并保留50%的IO帶寬資源冗余。此外，從分區(qū)副本限制考慮，每個(gè)Broker不應(yīng)超過2000個(gè)分區(qū)副本；整個(gè)集群不應(yīng)超過200,000個(gè)分區(qū)副本。如果預(yù)估集群總分區(qū)副本數(shù)量會(huì)比較多，建議您從總分區(qū)數(shù)來評(píng)估所需Broker的節(jié)點(diǎn)數(shù)。

  說明

  Broker節(jié)點(diǎn)數(shù) = Max（4，數(shù)據(jù)峰值流入 * （扇出因子 + 2 * 分區(qū)副本因子-1) * 2 / 400 MB/s）。

• 估算每個(gè)Broker的CU數(shù)量：由于所需CU數(shù)量與集群配置、客戶端配置及其使用方式、分區(qū)數(shù)量、集群規(guī)模、Consumer個(gè)數(shù)、Producer個(gè)數(shù)等都有關(guān)系，難以估算。建議您創(chuàng)建生產(chǎn)集群時(shí)，每個(gè)Broker使用8 CU以上每Broker的配置，開發(fā)測(cè)試集群使用4 CU每Broker的配置。同時(shí)，建議您每4 CU的Broker上不應(yīng)超過100個(gè)leader副本或300個(gè)分區(qū)副本（包含leader副本）。

• 估算每個(gè)Broker的磁盤大小：每個(gè)Broker的磁盤大小 = Max（1TB，數(shù)據(jù)平均流入 * 數(shù)據(jù)保留時(shí)長 * 分區(qū)副本因子 / Broker節(jié)點(diǎn)數(shù)）。

Connect資源評(píng)估

• 節(jié)點(diǎn)數(shù)評(píng)估：建議選擇2個(gè)節(jié)點(diǎn)以上以保證Connect為高可用的。

• CU評(píng)估：建議選擇每個(gè)節(jié)點(diǎn)8 CU以上。

Schema Resgitry資源評(píng)估

• Schema Resgitry生產(chǎn)環(huán)境建議配置2個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)2 CU。

Control Center資源評(píng)估

• Control Center生產(chǎn)環(huán)境建議配置1個(gè)節(jié)點(diǎn)，計(jì)算資源為4 CU以上，數(shù)據(jù)存儲(chǔ)300 GB以上。

ksqlDB資源評(píng)估

• 節(jié)點(diǎn)數(shù)評(píng)估：建議選擇2個(gè)節(jié)點(diǎn)以上以保證REST Proxy為高可用的。

• CU評(píng)估：建議選擇每個(gè)節(jié)點(diǎn)4 CU以上。

• 存儲(chǔ)評(píng)估：ksqlDB的存儲(chǔ)大小依賴于聚合語句以及并發(fā)查詢的數(shù)量，默認(rèn)選擇100 GB。

REST Proxy資源評(píng)估

• 節(jié)點(diǎn)數(shù)評(píng)估：建議選擇2個(gè)節(jié)點(diǎn)以上以保證REST Proxy為高可用的。

• CU評(píng)估：如果您需要通過REST Proxy進(jìn)行消息的持續(xù)生產(chǎn)和消費(fèi)，您需要選擇每個(gè)節(jié)點(diǎn)8 CU以上；否則，您可以選擇每個(gè)節(jié)點(diǎn)4 CU。

集群資源性能對(duì)比

下表展示了不同CU個(gè)數(shù)下，集群的總吞吐量變化，以及單個(gè)Producer時(shí)延變化。您可以根據(jù)業(yè)務(wù)的數(shù)據(jù)流量以及時(shí)延要求，選擇合適的集群CU個(gè)數(shù)。

默認(rèn)情況下，云消息隊(duì)列 Confluent 版集群為4 Broker規(guī)格，具備400 MB/s吞吐量的集群性能。如果您希望增加集群的吞吐量性能，可以對(duì)集群進(jìn)行水平擴(kuò)容。每新增加一個(gè)Broker，集群吞吐量性能增加100 MB/s。

下表列出了不同Broker個(gè)數(shù)下，對(duì)應(yīng)的集群吞吐量性能、消息處理能力，以及能夠支持的Partion數(shù)量。

集群規(guī)格選擇建議

以下給出典型場景下的集群規(guī)格建議，您也可以參考Confluent官網(wǎng)指導(dǎo)文檔。

集群組件資源分配規(guī)則

下表列出各組件的資源配置范圍。

相關(guān)文檔

Confluent提供了針對(duì)Kafka和Confluent Platform的資源評(píng)估工具，該工具適用于云消息隊(duì)列 Confluent 版，詳情請(qǐng)參見Sizing Calculator for Apache Kafka and Confluent Platform。