Kafka使用最佳實踐-Kafka集群部署規范

Kafka集群部署規范

1.CPU規格與掛盤數量的關系規范

根據FusionInsight HD產品文檔中所述的硬件要求來選擇合適的部署方式。對于kafka組件需要關注機器中具體處理器超線程個數，即processor的個數，可以通過命令：grep -c processor /proc/cpuinfo 查看。這個參數代表了整個機器的處理能力，kafka默認，建議：每臺機器最大掛盤數量 <= processor / 2

例如：機器的processor數量為24，那么這個機器的最大掛盤數為12塊。

2.磁盤掛載規范

Kafka在1.x版本（FI對應版本為6.5.x）之前，對于磁盤容錯方面做的不夠完善，如果單臺節點如果出現一塊磁盤故障，那么這個節點的kafka進程就會出現異常，因此，不建議每個broker節點掛載多個單盤。

使用建議：建議每臺機器使用raid5來掛載磁盤。單臺機器可以掛載多個raid5的邏輯盤，每塊邏輯盤的物理盤個數可以按照需求指定。

3.Topic創建規范

kafka的一個topic通常代表了一類數據，合理的創建topic是保持kafka集群健壯的基本因素。 標準的topic使用建議如下：

不可無休止的創建而不刪除topic。kafka集群的topic數量（或者說topic的分區總量）有一定限，上限根據集群的性能而定。一旦整個集群的分區總量到達上限，會導致kafka集群無法正常服務，建議集群中topic總量不超過2000，每個節點的分區總量不超過2000。

使用建議：如果業務重要或者數據量很大，建議分區量=節點數*磁盤數，如果該數值大于200，則分區數選擇為200，如果后期需要需要提升分區數來提升讀寫性? ? ? ?能，可以使用kafka后臺命令逐步提升，如果數據量很小，建議分區量=節點數，保證每個節點的數據量均衡。

b.副本數不可配太多。副本是kafka容錯能力的基礎，當kafka出現節點故障后，另外的副本會承擔leader接收數據責任。副本數增加一個，就需要多一次數據同步，也會使 kafka節點之間的數據流量同步能加一次。如果副本太多會。導致leader節點的數據流量壓力增加。

使用建議：創建的topic有2~3備份即可。

c. 機架參數要合理使用。FusionInsight-HD中的kafka集群默認使用了機架感知策略，即：保證kafka所創建的topic的分區副本在不同的機架上面，這樣能夠保證如果出現機架宕機后，kafka依然有可用的副本。但是如果集群中每個機架上面的節點數量不均衡，會導致嚴重的數據傾斜。例如：kafka總共有2個機架10臺機器，如果一個機架上有3個節點，一個機架上面有7個節點，那么3節點機架上的機器的副本數一定大于7節點機架的。

使用建議：如果kafka集群的機器在每個機架上面分布不均衡，在創建topic的時候加入機架不感知參數。

創建方式如下,其中ZK_IP為集群zookeeper的ip:

kafka-topics.sh --create --topic --partitions --replication-factor --zookeeper --disable-rack-aware

d. 不可頻繁的創建刪除topic。topic的創建目的應該是一次創建，長時間使用，如果topic出現異常可以刪除重建。如果頻繁創建，會導致broker節點異常，topic無法正常刪除，同時對zookeeper也會造成一定的壓力（頻繁的創建刪除，也就是頻繁的增刪zookeeper上面的節點，如果頻率很大容易導致“羊群效應”和“腦裂”）。例如：每天大批量的創建刪除1000個。

使用建議：

如果有刪除topic需要。每天刪除量不建議超過10個。

規整數據的協議類型，將多個相同類型的數據合并到一個topic中，創建后長期使用。防止出現topic頻繁創建刪除的情形。

4.集群性能調優

Kafka的集群調優通常考慮維度主要有兩個，第一，是磁盤讀寫能力，第二，網絡帶寬。

磁盤的讀寫的負載可以通過命令：iostat –x -1 查看 idle指標，這個值越大代表磁盤越空閑。萬兆網卡的極限能力為1250M/s，網絡速度可以通過前臺界面的，主機管理->對應主機“網絡寫入速度”，“網絡讀取速度”獲取。通常在性能的極限情況下，磁盤io會成為性能瓶頸。Kafka側優化寫入性能的參數如下：

配置項

缺省值

調優場景

num.recovery.threads.per.data.dir

10

每個數據目錄用來數據恢復的線程數目。在Kafka啟動過程中，數據量較大情況下，可調大此參數，可以提升啟動速度。

background.threads

10

Broker后臺任務處理的線程數目。數據量較大的情況下，可適當調大此參數，以提升Broker處理能力。

num.replica.fetchers

1

副本向Leader請求同步數據的線程數。增大這個數值會增加副本的I/O并發度。

num.network.threads

3

Broker用來處理網絡請求的線程數目

num.io.threads

8

Broker用來處理磁盤I/O的線程數目。這個線程數目建議至少等于硬盤的個數。

queued.max.requests

500

指定用于緩存網絡請求的隊列的最大容量，這個隊列達到上限之后將不再接收新請求。

在網絡線程停止讀取新請求之前，可以排隊等待I/O線程處理的最大請求個數。增大queued.max.requests能夠緩存更多的請求，以撐過業務峰值。如果過大，會造成內存的浪費。

socket.receive.buffer.bytes

102400

服務端接收緩沖區大小，增加該參數能夠提升生產、消費數據在緩沖區的數量，從而提升網絡傳輸的吞吐量

socket.send.buffer.bytes

102400

服務端發送緩沖區大小，增加該參數能夠提升生產、消費數據在緩沖區的數量，從而提升網絡傳輸的吞吐量

replica.socket.receive.buffer.bytes

65536

備份時向leader發送網絡請求時的socket receive buffer

replica.lag.max.messages

4000

如果一個副本中沒有同步的消息條數超過這個數值，Leader會認為該副本已經失效，并將其從ISR中移除。

KAFKA_HEAP_OPTS

-Xmx6G -Xms6G

Kafka內存占用參數配置。

kafka集群的性能參數調整到最優值后，kafka數據的處理能力會大幅度提升cpu的使用率也會增加。如果后續節點上的數據流量持續增長，CPU的使用率也會上升。

5. Kafka性能維度標準

5.1性能維度

6.5.1版本之后kafka生產者的性能基線標準

如何判斷一個kafka集群是否已經處于性能瓶頸，通常的判斷條件有如下幾點：

維度1：磁盤IO

讀寫磁盤性能是kafka重要的參數指標，如果磁盤IO到達性能瓶頸會直接導致業務故障。Kafka讀寫性能跟磁盤IO之間的關系計算如下：

舉例：假設磁盤IO的上限為100M/s，數據大小為8k，假設在topic僅設置為單副本的情況下，理論上一塊盤能寫入的數據量為100*1024/8=12800條。如果一個節點掛載4塊盤，那么理論性能為4*12800條。如果kafka集群有4個節點，那么整個集群的性能為4*4*12800條。

維度2：網絡IO

現網的網卡設置一般為萬兆網卡，一張萬兆網卡的理論極限性能為1250MB/s，在多kafka集群場景下，如果每個節點的數據流量不超過這個值，網卡一般不會出現性能瓶頸。

維度3：CPU使用率

Kafka使用CPU的地方主要在請求的處理、數據落盤等，如果CPU使用率頻繁出現95%以上的情況表示kafka集群性能已經到達瓶頸。通常影響kafka集群CPU使用率的幾個參數主要有以下幾個：

num.recovery.threads.per.data.dir，background.threads，num.replica.fetchers，num.network.threads，num.io.threads。具體參數含義見1.4章節。在磁盤和網卡未達到瓶頸的前提下，如果CPU使用率未達到上限，可以適當調大num.io.threads和num.network.threads，以提升kafka的集群處理能力。

以上三個性能指標哪個先達到瓶頸就是kafka集群的瓶頸。

5.2接口基線性能

異步producer性能數據

message.size

batch.size

total.data.sent.in.MB

MB.sec

total.data.sent.in.nMsg

nMsg.sec

50

200

4768.37

64.4671

99999984

1351972.3116

100

200

9536.74

120.8835

99999984

1267555.4429

150

200

14305.11

231.6430

99999984

1619301.8217

200

200

19073.48

187.9179

99999984

985231.2240

512

200

48828.12

391.3607

99999984

801506.7046

1024

200

97656.23

539.1827

99999984

552123.1014

2048

200

1953.09

249.6924

999984

127842.4955

隨著消息大小變大，吞吐量增加，每秒處理的消息條數逐漸變少。

同步producer性能數據

message.size

batch.size

total.data.sent.in.MB

MB.sec

total.data.sent.in.nMsg

nMsg.sec

50

200

476.84

2.9943

9999984

62795.0367

100

200

953.67

5.8847

9999984

61705.8232

150

200

1430.51

8.6639

9999984

60565.2198

200

200

1907.35

11.1892

9999984

58663.6631

512

200

4882.80

28.0556

9999984

57457.9637

1024

200

9765.61

49.8378

9999984

51033.8661

2048

200

19531.22

77.4646

9999984

39661.8583

Producer同步發送的性能每秒在6萬條左右。

Consumer性能數據

Batch-size

fetch.size

data.consumed.in.MB

MB.sec

data.consumed.in.nMsg

nMsg.sec

50

1048576

9536.7416

185.8833

99999984

1949127.5

100

1048576

9536.7416

215.0142

99999984

2254587.7

200

1048576

9536.7416

180.381

99999984

1891431.5

500

1048576

9536.7416

195.9712

99999984

2054906.8

1000

1048576

9536.7416

197.8167

99999984

2074258.1

2000

1048576

9536.7416

194.8103

99999984

2042733.7

5000

1048576

9536.7416

232.1053

99999984

2433800.2

100000

1048576

9536.7416

195.5372

99999984

2050356.4

100000

1048576

9536.7416

227.2059

99999984

382426.84

隨著Batch-size增加，消費者每秒消費的消息條數增加。以上場景的硬件信息如下：

硬件配置如下：

l???CPU：32core 2.0GHZ

l???內存：128G

l???硬盤：2*（SAS OS盤）+12*2.7T（SATA）

l???Broker節點數：2個

l Kafka使用的配置：num.io.thread=8

其它場景下，異步模式下生產、消費性能基線見附件：性能基線-kafka

EI企業智能 FusionInsight Kafka

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。