搞定這8個Kafka生產級容量評估,每日10億+請求輕鬆拿捏!

語言: CN / TW / HK

本篇文章通過場景驅動的方式來深度剖析 Kafka 生產級容量評估方案如何分析,申請和實施。

一、kafka容量評估需求場景分析

1、叢集如何每天hold住10億+請求

拿電商平臺為例,kafka 叢集每天需要承載10億+請求流量資料,一天24小時,對於平臺來說,晚上12點到凌晨8點這8個小時幾乎沒多少資料湧入的。這裡我們使用 「二八法則」 來進行預估,也就是80%的資料(8億)會在剩餘的16個小時湧入,且8億中的80%的資料(約6.4億)會在這16個小時的20%時間 (約3小時)湧入。

通過上面的場景分析,可以得出如下:

QPS計算公式 = 640000000 ÷ (3 * 60 * 60) = 6萬, 也就是說高峰期叢集需要扛住每秒6萬的併發請求。

假設 每條資料平均按20kb(生產端有資料彙總) 來算, 那就是 1000000000 * 20kb = 18T, 一般情況下我們都會設定 3個副本, 54T, 另外 kafka 資料是有保留時間週期的,  一般情況是保留 最近3天的資料, 54T * 3 = 162T。

2、場景總結

要搞定 10億+ 請求,高峰期要支撐 6萬QPS, 需要大約 162T 的儲存空間。

二、kafka容量評估之物理機數量

1、物理機 OR 虛擬機器

一般對於Kafka,Mysql,Hadoop 等叢集自建的時候,都會使用物理機來進行搭建,效能和穩定性相對虛擬機器要強很多。

2、物理機數量計算

第一步 中我們分析得出 系統高峰期 的時候要支撐 6萬QPS, 如果公司資金和資源充足的情況下,我們一般會讓高峰期的QPS控制在叢集總承載QPS能力的 30%左右, 這樣的話可以得出叢集能承載的 總QPS能力約為20萬左右, 這樣系統才會是安全的。

3、場景總結

根據經驗可以得出 每臺物理機支撐4萬QPS 是沒有問題的,從QPS角度分析,我們要支撐 10億+ 請求,大約需要 5臺物理機, 考慮到消費者請求,需要增加約1.5倍機器,即 7臺物理機。

三、kafka容量評估之磁碟

1、機械硬碟 OR 固態硬碟SSD

兩者主要區別如下:

  • SSD就是固態硬碟,它的優點是速度快,日常的讀寫比機械硬碟快幾十倍上百倍。缺點是單位成本高,不適合做大容量儲存。

  • HDD就是機械硬碟,它的優點是單位成本低,適合做大容量儲存,但速度遠不如SSD。

首先SSD硬碟效能好,主要是指的隨機讀寫能力效能好,非常適合Mysql這樣的叢集,而 SSD的順序讀寫效能跟機械硬碟的效能是差不多的。

Kafka 寫磁碟是順序追加寫的, 所以對於 kafka 叢集來說,我們使用 普通機械硬碟 就可以了。

2、每臺伺服器需要多少塊硬碟

根據 第一二步驟 計算結果,我們需要 7臺物理機, 一共需要儲存 162T 資料,大約每臺機器需要儲存 23T 資料,根據以往經驗一般伺服器配置 11塊 硬碟,這樣每塊硬碟大約儲存2T的資料就可以了,另外為了伺服器效能和穩定性,我們一般要保留一部分空間,保守按每塊硬碟 最大能儲存3T資料。

3、場景總結

要搞定 10億+ 請求,需要 7臺物理機, 使用 普通機械硬碟 進行儲存,每臺伺服器 11塊 硬碟,每塊硬碟儲存 2T 資料。

四、kafka容量評估之記憶體

1、Kafka 寫磁碟流程及記憶體分析

從上圖可以得出 Kafka 讀寫資料的流程主要都是基於os cache,所以基本上 Kafka 都是基於記憶體來進行資料流轉的,這樣的話要 分配儘可能多的記憶體資源給os cache。

kafka的核心原始碼基本都是用 scala 和 java (客戶端)寫的,底層都是基於 JVM 來執行的,所以要分配一定的記憶體給 JVM 以保證服務的穩定性。對於 Kafka 的設計,並沒有把很多的資料結構儲存到 JVM 中, 所以根據經驗,給 JVM 分配6~10G就足夠了。

從上圖可以看出一個 Topic 會對於多個 partition,一個 partition 會對應多個 segment ,一個 segment 會對應磁碟上4個log檔案。假設我們這個平臺總共100個 Topic ,那麼總共有 100 Topic * 5 partition * 3 副本 = 1500 partition 。 對於 partition 來說實際上就是物理機上一個檔案目錄, .log就是儲存資料檔案的,預設情況下一個 .log日誌檔案大小為1G。

如果要保證這1500個 partition 的最新的 .log 檔案的資料都在記憶體中,這樣效能當然是最好的,需要 1500  * 1G = 1500 G 記憶體,但是我們沒有必要所有的資料都駐留到記憶體中,我們只保證 25%左右 的資料在記憶體中就可以了,這樣大概需要 1500 * 250M = 1500 * 0.25G = 375G記憶體, 通過 第二步 分析結果,我們總共需要 7臺物理機, 這樣的話 每臺伺服器只需要約54G記憶體,外加上面分析的JVM的10G,總共需要64G記憶體。 還要保留一部分記憶體給作業系統使用,故我們選擇 128G記憶體的伺服器 是非常夠用了。

2、場景總結

要搞定 10億+ 請求,需要 7臺物理機, 每臺物理機記憶體選擇 128G記憶體 為主,這樣記憶體會比較充裕。

五、kafka容量評估之CPU壓力

1、CPU Core分析

我們評估需要多少個 CPU Core,主要是看 Kafka 程序裡會有多少個執行緒, 執行緒主要是依託多核CPU來執行的,如果執行緒特別多,但是 CPU核很少,就會導致CPU負載很高,會導致整體工作執行緒執行的效率不高,效能也不會好。 所以我們要保證CPU Core的充足,來保障系統的穩定性和效能最優。

2、Kafka 網路架構及執行緒數計算

我們評估下 Kafka 伺服器啟動後會有多少執行緒在跑,其實這部分內容跟kafka超高併發網路架構密切相關, 上圖是Kafka 超高併發網路架構圖, 從圖中我們可以分析得出:

除了上圖所列的還有其他一些執行緒,所以估算下來,一個 kafka 服務啟動後,會 有100多個執行緒在跑。

2、場景總結

要搞定 10億+ 請求,需要 7臺物理機, 每臺物理機記憶體選擇 128G記憶體 為主,需要 16個cpu core(32個性能更好)。

六、kafka容量評估之網絡卡

1、網絡卡對比分析

通過上圖分析可以得出 千兆網絡卡和萬兆網絡卡的區別最大之處在於網口的傳輸速率的不同,千兆網絡卡的傳輸速率是1000Mbps,萬兆網絡卡的則是10Gbps萬兆網絡卡是千兆網絡卡傳輸速率的10倍。 效能上講,萬兆網絡卡的效能肯定比千兆網絡卡要好。萬兆網絡卡現在主流的是10G的,發展趨勢正逐步面向40G、100G網絡卡。但還是要根據使用環境和預算來選擇投入,畢竟千兆網絡卡和萬兆網絡卡的價效比區間還是挺大的。

2、網絡卡選擇分析

根據 第一二步 分析結果,高峰期的時候,每秒會有大約 6萬 請求湧入,即每臺機器 約1萬 請求湧入 (60000 / 7), 每秒要接收的資料大小為: 10000 * 20 kb = 184 M/s, 外加上資料副本的同步網路請求,總共需要 184 * 3 = 552 M/s。

一般情況下,網絡卡頻寬是不會達到上限的,對於千兆網絡卡,我們能用的基本在700M左右, 通過上面計算結果,千兆網絡卡基本可以滿足,萬兆網絡卡更好。

3、場景總結

要搞定 10億+ 請求,需要 7臺物理機, 每臺物理機記憶體選擇 128G記憶體 為主,需要 16個cpu core(32個性能更好),千兆網絡卡基本可以滿足,萬兆網絡卡更好。

7、kafka容量評估之核心引數

8、kafka容量評估之叢集規劃

1、叢集部署規劃

這裡我採用五臺伺服器來構建 Kafka 叢集,叢集依賴 ZooKeeper,所以在部署 Kafka 之前,需要部署好 ZooKeeper 叢集。這裡我將 Kafka 和 ZooKeeper 部署在了一起,Kafka 叢集節點作業系統仍然採用 Centos 7.7 版本,各個主機角色和軟體版本如下表所示:

這裡需要注意: Kafka 和 ZooKeeper 的版本,預設 Kafka2.11 版本自帶的 ZooKeeper 依賴 jar 包版本為 3.5.7,因此 ZooKeeper 的版本至少在 3.5.7 及以上。

2、下載與安裝

Kafka 需要安裝 Java 執行環境,你可以點選Kafka官網

(http://kafka.apache.org/downloads)獲取 Kafka 安裝包,推薦的版本是 kafka_2.11-2.4.1.tgz。將下載下來的安裝包直接解壓到一個路徑下即可完成 Kafka 的安裝,這裡統一將 Kafka 安裝到 /usr/local 目錄下,我以在 kafka-zk1 主機為例,基本操作過程如下:

[[email protected]~]# tar -zxvf kafka_2.11-2.4.1.tgz  -C /usr/local
[[email protected]~]# mv /usr/local/kafka_2.11-2.4.1 /usr/local/kafka

這裡我建立了一個 Kafka 使用者,用來管理和維護 Kafka 叢集,後面所有對 Kafka 的操作都通過此使用者來完成,執行如下操作進行建立使用者和授權:

[[email protected]~]# useradd kafka
[[email protected]~]# chown -R kafka:kafka /usr/local/kafka

在 kafka-zk1 節點安裝完成 Kafka 後,先進行配置 Kafka,等 Kafka 配置完成,再統一打包複製到其他兩個節點上。

broker.id=1
listeners=PLAINTEXT://172.16.213.31:9092
log.dirs=/usr/local/kafka/logs
num.partitions=6
log.retention.hours=72
log.segment.bytes=1073741824
zookeeper.connect=172.16.213.31:2181,172.16.213.32:2181,172.16.213.33:2181
auto.create.topics.enable=true
delete.topic.enable=true
num.network.threads=9
num.io.threads=32
message.max.bytes=10485760
log.flush.interval.message=10000
log.flush.interval.ms=1000
replica.lag.time.max.ms=10

Kafka 配置檔案修改完成後,接著打包 Kafka 安裝程式,將程式複製到其他4個節點,然後進行解壓即可。 注意,在其他4個節點上,broker.id 務必要修改,Kafka 叢集中 broker.id 不能有相同的(唯一的)。  

3、啟動叢集

五個節點的 Kafka 配置完成後,就可以啟動了,但在啟動 Kafka 叢集前,需要確保 ZooKeeper 叢集已經正常啟動。接著,依次在 Kafka 各個節點上執行如下命令即可:

[[email protected]~]# cd /usr/local/kafka
[[email protected] kafka]# nohup bin/kafka-server-start.sh config/server.properties &
[[email protected] kafka]# jps
21840 Kafka
15593 Jps
15789 QuorumPeerMain

這裡將 Kafka 放到後臺(deamon)執行,啟動後,會在啟動 Kafka 的當前目錄下生成一個 nohup.out 檔案,可通過此檔案檢視 Kafka 的啟動和執行狀態。 通過 jps 指令,可以看到有個 Kafka 標識,這是 Kafka 程序成功啟動的標誌。

九、總結

整個場景總結:

要搞定 10億+ 請求,經過上面深度剖析評估後需要以下資源:

作者丨王江華

來源丨公眾號:華仔聊技術(ID:gh_97b8de4b5b34)

dbaplus社群歡迎廣大技術人員投稿,投稿郵箱: [email protected]