Kafka最佳實(shí)踐-Kafka常見(jiàn)的使用誤區(qū)

1.? kafka集群?jiǎn)蝹€(gè)節(jié)點(diǎn)磁盤(pán)掛載的越多越好

業(yè)界Kafka的標(biāo)準(zhǔn)使用方式是作為臨時(shí)緩存使用。因此，很多人會(huì)誤以為，kafka的每個(gè)節(jié)點(diǎn)只要存儲(chǔ)夠大就行，不用關(guān)心其他的指標(biāo)。官方并不建議kafka單節(jié)點(diǎn)關(guān)在多個(gè)磁盤(pán)，因?yàn)榇疟P(pán)越多，表示需要更多的處理線程去管理（num.io.thread決定），CPU的壓力將非常大，如果磁盤(pán)數(shù)大于了CPU邏輯核數(shù)，kafka的CPU將因?yàn)榉浅７泵?dǎo)致數(shù)據(jù)落盤(pán)失敗，從而影響業(yè)務(wù)。

建議：

建議每個(gè)節(jié)點(diǎn)掛盤(pán)數(shù)，滿足每臺(tái)機(jī)器最大掛盤(pán)數(shù)量 <= processor（CPU邏輯核數(shù)） / 2。

最優(yōu)策略為每個(gè)節(jié)點(diǎn)使用raid5或者raid10掛載數(shù)據(jù)目錄，每個(gè)raid5或者raid10的邏輯盤(pán)不超過(guò)8塊。

2.? 把kafka當(dāng)做數(shù)據(jù)庫(kù)使用

很多人認(rèn)為，如果數(shù)據(jù)重要，需要把kafka中的數(shù)據(jù)保存周期延長(zhǎng)到很大（例如：1年），例如。Kafka對(duì)于數(shù)據(jù)目錄中的每個(gè)segment文件會(huì)有一個(gè)操作句柄對(duì)應(yīng)，如果數(shù)據(jù)保存周期過(guò)長(zhǎng)，會(huì)導(dǎo)致操作句柄使用率增加，如果句柄數(shù)無(wú)限制增加并且到達(dá)上限后會(huì)導(dǎo)致kafka服務(wù)異常。

正常情況下，業(yè)務(wù)側(cè)應(yīng)當(dāng)根據(jù)集群中的磁盤(pán)總?cè)萘縼?lái)評(píng)估數(shù)據(jù)的保留時(shí)間。如果，集群中的業(yè)務(wù)種類多、數(shù)據(jù)量大。于此同時(shí)又不關(guān)心數(shù)據(jù)量的大小，很容易造成磁盤(pán)容量不足。

建議：

建議業(yè)務(wù)側(cè)評(píng)估好數(shù)據(jù)量的大小，調(diào)整合適的保留時(shí)間。一般情況下，建議使用7天即可。

3.? 分區(qū)數(shù)越多越好

Kafka增加分區(qū)數(shù)的作用主要有兩點(diǎn)：第一：將數(shù)據(jù)分布均勻，防止不會(huì)出現(xiàn)某個(gè)節(jié)點(diǎn)或者某個(gè)數(shù)據(jù)盤(pán)的數(shù)據(jù)熱點(diǎn)。第二，提升消費(fèi)并行度，消費(fèi)者通常與分區(qū)是一一對(duì)應(yīng)的，提升分區(qū)數(shù)同樣也能提升消費(fèi)者的個(gè)數(shù)，從而提升消費(fèi)性能。但是分區(qū)數(shù)不能無(wú)限制增加，如果數(shù)量太多會(huì)導(dǎo)致kafka和zookeeper負(fù)載增高，kafka內(nèi)部調(diào)度線程無(wú)法及時(shí)處理響應(yīng)，導(dǎo)致節(jié)點(diǎn)進(jìn)程故障。

建議：

建議集群中topic總量不超過(guò)2000，每個(gè)節(jié)點(diǎn)的分區(qū)總量不超過(guò)2000。

如果業(yè)務(wù)重要或者數(shù)據(jù)量很大，建議分區(qū)量=節(jié)點(diǎn)數(shù)*磁盤(pán)數(shù)，如果該數(shù)值大于200，則分區(qū)數(shù)選擇為200，如果后期需要提升分區(qū)數(shù)來(lái)提升讀寫(xiě)性能，可以使用kafka后臺(tái)命令逐步提升，如果數(shù)據(jù)量很小，建議分區(qū)量=節(jié)點(diǎn)數(shù)，保證每個(gè)節(jié)點(diǎn)的數(shù)據(jù)量均衡。

4.? 業(yè)務(wù)側(cè)對(duì)寫(xiě)入kafka的數(shù)據(jù)大小不感知

kafka組件的主要定位為消息隊(duì)列（非文件隊(duì)列），官方建議寫(xiě)入kafka最佳的數(shù)據(jù)大小不超過(guò)15K。但是在很多的業(yè)務(wù)場(chǎng)景下，需要寫(xiě)入的數(shù)據(jù)往往是大于15k的。Kafka服務(wù)端默認(rèn)可以接受的最大的數(shù)據(jù)大小為10M

建議：

客戶端默認(rèn)單條數(shù)據(jù)大小最大為1M（由配置request.size決定），在數(shù)據(jù)大小小于1M的情況下，使用默認(rèn)值發(fā)送數(shù)據(jù)即可。

如果數(shù)據(jù)在1M到5M之間，開(kāi)啟在生產(chǎn)端開(kāi)啟壓縮模式（由type決定，可以選擇gzip,?snappy, 或者lz4），開(kāi)啟壓縮后，生產(chǎn)端的壓縮數(shù)據(jù)過(guò)程和消費(fèi)端的解壓縮數(shù)據(jù)過(guò)程會(huì)增加CPU的使用率。

不建議發(fā)送大于5M的數(shù)據(jù)，經(jīng)過(guò)驗(yàn)證持續(xù)返送大于5M的數(shù)據(jù)會(huì)導(dǎo)致kafka的直接內(nèi)存溢出。

5.? ? ? Topic可以隨意的創(chuàng)建和刪除

Kafka的topic代表了一個(gè)類型的數(shù)據(jù)，頻繁的創(chuàng)建刪除topic會(huì)導(dǎo)致zookeeper通信壓力大，出現(xiàn)broker節(jié)點(diǎn)信息上報(bào)失敗，服務(wù)不可用的情況。一旦zookeeper出現(xiàn)異常，刪除topic的流程會(huì)處于阻塞狀態(tài)，導(dǎo)致topic無(wú)法正常刪除。

建議：

Topic不建議頻繁創(chuàng)建刪除。

對(duì)于有共同特點(diǎn)的數(shù)據(jù)（例如：協(xié)議類型相同），可以歸并到一個(gè)topic里面處理。

6.? ?頻繁使用舊版本客戶端消費(fèi)工具

舊版本的消費(fèi)工具使用的命令如下：

每使用一次就會(huì)在zookeeper下生成一個(gè)永久節(jié)點(diǎn)。這個(gè)節(jié)點(diǎn)不會(huì)自動(dòng)清理，如果經(jīng)常使用會(huì)導(dǎo)致zookeeper異常。

EI企業(yè)智能 FusionInsight Kafka ZooKeeper

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。