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

kafka是一個高吞吐量分散式訊息系統，並且提供了持久化。其高效能的有兩個重要特點：（1）利用了磁碟連續讀寫效能遠遠高於隨機讀寫的特點；（2）併發，將一個topic拆分多個partition。
要充分發揮kafka的效能，就需要滿足這兩個條件。linkedin的測試，就把這兩個方面發揮到極致（參考http://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines）

(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) 記憶體相關設定

現在線上  預設的jvm記憶體堆分配較大（比如8g記憶體給jvm堆6g），導致系統其他可用記憶體比較小。pagecache是linux核心的低優先順序快取，在記憶體空間富裕的情況下才能獲得較大的空間。並且kafka不自建快取，堆空間需求也比較小。因此建議保留實體記憶體的1/2以上給系統，以便保證pagecache的分配。

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

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

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

num.network.threads=xxx

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

num.io.threads=xxx

建議配置：

一般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埠的，需要使用者自己配置

[[email protected] kafka_2.10-0.8.1]$ vim bin/kafka-run-class.sh

#最前面新增一行

JMX_PORT=8060
--------------------- 
作者：幽靈之使 
來源：CSDN 
原文：https://blog.csdn.net/lizhitao/article/details/42180265 
版權宣告：本文為博主原創文章，轉載請附上博文連結！