kafka server部署配置優化

1.kafka高效能的特點及條件

kafka是乙個高吞吐量分布式訊息系統，並且提供了持久化。其高效能的有兩個重要特點：（1）利用了磁碟連續讀寫效能遠遠高於隨機讀寫的特點；（2）併發，將乙個topic拆分多個partition。

要充分發揮kafka的效能，就需要滿足這兩個條件。linkedin的測試，就把這兩個方面發揮到極致（參考

(1)磁碟的連續性

要充分利用磁碟連續讀寫高效能的特點，就意味著要減少作業系統對磁碟的重新排程。kakfa內部的實現非常巧妙：

生產：網路 —> pagecache(記憶體) —>磁碟

消費：磁碟 —> 網路（使用sendfile將磁碟資料直接拷貝到網絡卡傳送緩衝區）

這樣的設計使得，寫磁碟的機會僅僅是pagecache需要flush到磁碟的時候；這樣保證了大多數時候磁碟可以連續地讀取，而且直接複製到網絡卡，避免消費影響到生產（寫入記憶體）。另外，使用檔案系統pagecache而不是自建快取，還利用pagecache對於 sendfile來說是透明的優勢，也就是在沒有訊息堆積時，資料流動實際時pagecahe直接到網絡卡，減少磁碟io又保證及時消費。

(2)併發，將topic拆分多個partition

kafka讀寫的單位是partition，因此，將乙個topic拆分為多個partition可以提高吞吐量。但是，這裡有個前提，就是不同partition需要位於不同的磁碟（可以在同乙個機器）。如果多個partition位於同乙個磁碟，那麼意味著有多個程序同時對乙個磁碟的多個文件進行讀寫，使得作業系統會對磁碟讀寫進行頻繁排程，也就是破壞了磁碟讀寫的連續性。

在linkedlin的測試中，每台機器就載入了6個磁碟，並且不做raid，就是為了充分利用多磁碟併發讀寫，又保證每個磁碟連續讀寫的特性。

具體配置上，是將不同磁碟的多個目錄配置到broker的log.dirs，例如

log.dirs=/disk1/kafka-logs,/disk2/kafka-logs,/disk3/kafka-logs

kafka會在新建partition的時候，將新partition分布在partition最少的目錄上，因此，一般不能將同乙個磁碟的多個目錄設定到log.dirs

2.kafka在虛擬機器環境的優化

kafka高效能很大程度依賴於磁碟（檔案系統）的連續讀寫，而在虛擬機器環境中，檔案系統一些不同的特點，因此做好這些優化很有必要。

(1)虛擬檔案系統的特點

通常，虛擬機器不會直接使用物理磁碟（儘管可以）。多個物理磁碟或者raid陣列被宿主系統虛擬成乙個大的磁碟，再分配各個虛擬機器。對於虛擬檔案系統來說，有2個特點比較重要

寫優先。大多數虛擬檔案系統為了保證磁碟資料的更新，都會一定程度保證寫優先

非連續。對於可變大小的虛擬磁碟，通常再需要空間的時候再進行實際分配，造成邏輯上連續的檔案，物理儲存並不一定連續

高效能。為了支援多個虛擬機器同時執行，合理的情況下配置的整體磁碟效能會比較高

不穩定。由於多個虛擬機器同時執行的互相影響，可能會出現資源爭奪導致的不穩定

(2)kafka在虛擬機器環境的優化

首先是，多磁碟的併發的問題。不管怎麼說，虛擬機器環境至少剝奪了單個kafka同時使用多個磁碟的優勢。也就意味著，在在同乙個虛擬機器，同乙個topic，最好只有乙個partition；當然，不同topic之間partition如果同時生產－消費也會互相影響，但不一定會同時在高峰（同個topic一定）。構建較大集群（在不同物理機）仍然能夠保持併發優勢。

其次，寫優先和不穩定也是需要考慮問題。如果多個topic同時寫入，或者其他虛擬機器搶占資源，可能會導致消費緩慢。因此，監控就顯得特別重要，對於消費過慢的partition 暫停寫入。由於pagecache缺省會使用所有可用記憶體，增加記憶體可以減少flush到磁碟的次數，使得讀取（消費）更加順利。

另外，為了保證讀寫連續性，kafka自身及其他服務不要和log.dir共享磁碟。在美團虛擬機器上，可以考慮將kafka 安裝在系統磁碟，資料盤(/opt)完全用於日誌儲存。

總結一下，kafka在虛擬機器環境的優化有三點：

第一，組建較大集群，並保證同乙個topic的不同partition位於不同虛擬機器（所以在不同的磁碟）

第二，監控，對於消費過慢的partition（所在的broker），暫停寫入（生產），等待消費

第三，將kafka安裝在系統盤，資料盤(/opt)完全用於訊息儲存。資料盤上不安裝其他服務

不得不提的是，以上結論在美團辦公雲（讀取200mb/s +）上測試有明顯的表現；。但是，良好的配置可以提公升穩定性，比如出現多個topic同時達到高峰，或者出現別的虛擬機搶占資源的時候，通常更不容易出現故障。

(3) 記憶體相關設定

配置優化都是修改server.properties檔案中引數值

1.網路和io操作執行緒配置優化

# broker處理訊息的最大執行緒數

num.network.threads=***

# broker處理磁碟io的執行緒數

num.io.threads=***

建議配置：

一般num.network.threads主要處理網路io，讀寫緩衝區資料，基本沒有io等待，配置執行緒數量為cpu核數加1.

num.io.threads主要進行磁碟io操作，高峰期可能有些io等待，因此配置需要大些。配置執行緒數量為cpu核數2倍，最大不超過3倍.

2.log資料檔案刷盤策略

為了大幅度提高producer寫入吞吐量，需要定期批量寫檔案。

建議配置：

# 每當producer寫入10000條訊息時，刷資料到磁碟

log.flush.interval.messages=10000

# 每間隔1秒鐘時間，刷資料到磁碟

log.flush.interval.ms=1000

3.日誌保留策略配置

當kafka server的被寫入海量訊息後，會生成很多資料檔案，且占用大量磁碟空間，如果不及時清理，可能磁碟空間不夠用，kafka預設是保留7天。

建議配置：

# 保留三天，也可以更短

log.retention.hours=72

# 段檔案配置1gb，有利於快速**磁碟空間，重啟kafka載入也會加快(如果檔案過小，則檔案數量比較多，

# kafka啟動時是單執行緒掃瞄目錄(log.dir)下所有資料檔案)

log.segment.bytes=1073741824

4.replica複製配置

每個follow從leader拉取訊息進行同步資料，follow同步效能由這幾個引數決定，分別為拉取執行緒數(num.replica.fetchers)、最小位元組數(replica.fetch.min.bytes)、最大位元組數(replica.fetch.max.bytes)、最大等待時間(replica.fetch.wait.max.ms)

建議配置：

num.replica.fetchers 配置多可以提高follower的i/o併發度，單位時間內leader持有跟多請求，相應負載會增大，需要根據機器硬體資源做權衡

replica.fetch.min.bytes=1 預設配置為1位元組，否則讀取訊息不及時

replica.fetch.max.bytes= 5 * 1024 * 1024 預設為1mb，這個值太小，5mb為宜，根據業務情況調整

replica.fetch.wait.max.ms follow拉取頻率，頻率過高，會導致cpu飆公升，因為leader無資料同步，leader會積壓大量無效請求情況，又因為0.8.2.x版本存在bug，定時器超時檢查比較消耗cpu，使用者需要做好權衡

5.配置jmx服務

kafka server中預設是不啟動jmx埠的，需要使用者自己配置

[lizhitao@root kafka_2.10-0.8.1]$ vim bin/kafka-run-class.sh

#最前面新增一行

kafka server部署配置優化

Kafka server部署配置優化

kafka server部署配置優化

Ice 配置部署

kafka server部署配置優化

Kafka server部署配置優化

kafka server部署配置優化

Ice 配置部署

相關推薦