kafka效能調優

主要最佳化原理和思路

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

要充分發揮kafka的效能，就需要滿足這兩個條件

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

同一個ConsumerGroup內的Consumer和Partition在同一時間內必須保證是一對一的消費關係

任意Partition在某一個時刻只能被一個Consumer Group內的一個Consumer消費(反過來一個Consumer則可以同時消費多個Partition) JVM參數配置

推薦使用最新的G1來代替CMS作為記憶體回收行程。
推薦使用的最低版本為JDK 1.7u51。下面是本次實驗中Broker的JVM記憶體配置參數：

-Xms30g -Xmx30g -XX:PermSize=48m -XX:MaxPermSize=48m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35

G1相比較於CMS的優勢： G1是一種適用於伺服器端的記憶體回收行程，很好的平衡了輸送量和響應能力 對於記憶體的劃分方法不同，Eden, Survivor, Old地區不再固定，使用記憶體會更高效。G1通過對記憶體進行Region的劃分，有效避免了記憶體片段問題。 G1可以指定GC時可用於暫停線程的時間（不保證嚴格遵守）。而CMS並不提供可控選項。 CMS只有在FullGC之後會重新合并壓縮記憶體，而G1把回收和合并集合在一起。 CMS只能使用在Old區，在清理Young時一般是配合使用ParNew，而G1可以統一兩類分區的回收演算法。

G1的適用情境： JVM佔用記憶體較大(At least 4G) 應用本身頻繁申請、釋放記憶體，進而產生大量記憶體片段時。 對於GC時間較為敏感的應用。

JVM參數詳解：http://blog.csdn.net/lizhitao/article/details/44677659 Broker參數配置

配置最佳化都是修改server.properties檔案中參數值

1. 網路和io操作線程配置最佳化

 # broker處理訊息的最大線程數  num.network.threads=xxx  # broker處理磁碟IO的線程數  num.io.threads=xxx 

建議配置：

用於接收並處理網路請求的線程數，預設為3。其內部實現是採用Selector模型。啟動一個線程作為Acceptor來負責建立串連，再配合啟動num.network.threads個線程來輪流負責從Sockets裡讀取請求，一般無需改動，除非上下遊並發請求量過大。一般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

Tips Kafka官方並不建議通過Broker端的log.flush.interval.messages和log.flush.interval.ms來強制寫盤，認為資料的可靠性應該通過Replica來保證，而強制Flush資料到磁碟會對整體效能產生影響。

可以通過調整/proc/sys/vm/dirty_background_ratio和/proc/sys/vm/dirty_ratio來調優效能。 髒頁率超過第一個指標會啟動pdflush開始Flush Dirty PageCache。 髒頁率超過第二個指標會阻塞所有的寫操作來進行Flush。 根據不同的業務需求可以適當的降低dirty_background_ratio和提高dirty_ratio。

如果topic的資料量較小可以考慮減少log.flush.interval.ms和log.flush.interval.messages來強制刷寫資料，減少可能由於快取資料未寫盤帶來的不一致。

4. 配置jmx服務
kafka server中預設是不啟動jmx連接埠的，需要使用者自己配置

[lizhitao@root kafka_2.10-0.8.1]$ vim bin/kafka-run-class.sh#最前面添加一行JMX_PORT=8060

5. Replica相關配置：

replica.lag.time.max.ms:10000replica.lag.max.messages:4000num.replica.fetchers:1#在Replica上會啟動若干Fetch線程把對應的資料同步到本地，而num.replica.fetchers這個參數是用來控制Fetch線程的數量。#每個Partition啟動的多個Fetcher，通過共用offset既保證了同一時間內Consumer和Partition之間的一對一關聯性，又允許我們通過增多Fetch線程來提高效率。default.replication.factor:1#這個參數指新建立一個topic時，預設的Replica數量#Replica過少會影響資料的可用性，太多則會白白浪費儲存資源，一般建議在2~3為宜。

6. purgatory

fetch.purgatory.purge.interval.requests:1000producer.purgatory.purge.interval.requests:1000

首先來介紹一下這個“煉獄”究竟是用來做什麼用的。Broker的一項主要工作就是接收並處理網路上發來的Request。這些Request其中有一些是可以立即回覆的，那很自然這些Request會被直接回複。另外還有一部分是沒辦法或者Request自發的要求延時回覆（例如發送和接收的Batch）,Broker會把這種Request放入Paurgatory當中，同時每一個加入Purgatory當中的Request還會額外的加入到兩個監控對隊列： WatcherFor隊列：用於檢查Request是否被滿足。 DelayedQueue隊列：用於檢測Request是否逾時。

Request最終的狀態只有一個，就是Complete。請求被滿足和逾時最終都會被統一的認為是Complete。

目前版本的Purgatory設計上是存在一定缺陷的。Request狀態轉變為Complete後，並沒能立即從Purgatory中移除，而是繼續佔用資源，因此佔用記憶體累積最終會引發OOM。這種情況一般只會在topic流量較少的情況下觸發。更詳細的資料可以查閱擴充閱讀，在此不做展開。

在實際使用中我也是踩了這個坑過來的，當時的情況是叢集新上了一個topic，初期該topic資料很少（Low volume topic），導致那段時間在淩晨3，4點左右會隨機有Broker因為OOM掛掉。定位原因後把*.purgatory.purge.interval.requests的配置調整小至100就解決了這個問題。

Kafka的研發團隊已經開始著手重新設計Purgatory，力求能夠讓Request在Complete時立即從Purgatory中移除。 其他

num.partitions:1#分區數量queued.max.requests:500#這個參數是指定用於緩衝網路請求的隊列的最大容量，這個隊列達到上限之後將不再接收新請求。一般不會成為瓶頸點，除非I/O效能太差，這時需要配合num.io.threads等配置一同進行調整。compression.codec:none#Message落地時是否採用以及採用何種壓縮演算法。一般都是把Producer發過來Message直接儲存，不再改變壓縮方式。in.insync.replicas:1#這個參數只能在topic層級配置，指定每次Producer寫操作至少要保證有多少個在ISR的Replica確認，一般配合request.required.acks使用。要注意，這個參數如果設定的過高可能會大幅降低輸送量。

Producer最佳化

buffer.memory:33554432 (32m)#在Producer端用來存放尚未發送出去的Message的緩衝區大小。緩衝區滿了之後可以選擇阻塞發送或拋出異常，由block.on.buffer.full的配置來決定。compression.type:none#預設發送不進行壓縮，推薦配置一種適合的壓縮演算法，可以大幅度的減緩網路壓力和Broker的儲存壓力。linger.ms:0#Producer預設會把兩次發送時間間隔內收集到的所有Requests進行一次彙總然後再發送，以此提高輸送量，而linger.ms則更進一步，這個參數為每次發送增加一些delay，以此來彙總更多的Message。batch.size:16384#Producer會嘗試去把發往同一個Partition的多個Requests進行合并，batch.size指明了一次Batch合并後Requests總大小的上限。如果這個值設定的太小，可能會導致所有的Request都不進行Batch。acks:1#這個配置可以設定發送訊息後是否需要Broker端返回確認。0: 不需要進行確認，速度最快。存在遺失資料的風險。1: 僅需要Leader進行確認，不需要ISR進行確認。是一種效率和安全折中的方式。all: 需要ISR中所有的Replica給予接收確認，速度最慢，安全性最高，但是由於ISR可能會縮小到僅包含一個Replica，所以設定參數為all並不能一定避免資料丟失。

Consumer最佳化

num.consumer.fetchers:1#啟動Consumer的個數，適當增加可以提高並發度。fetch.min.bytes:1#每次Fetch Request至少要拿到多少位元組的資料才可以返回。#在Fetch Request擷取的資料至少達到fetch.min.bytes之前，允許等待的最大時間長度。對應上面說到的Purgatory中請求的逾時時間。fetch.wait.max.ms:100

通過Consumer Group，可以支援生產者消費者和隊列訪問兩種模式。 Consumer API分為High level和Low level兩種。前一種重度依賴Zookeeper，所以效能差一些且不自由，但是超省心。第二種不依賴Zookeeper服務，無論從自由度和效能上都有更好的表現，但是所有的異常(Leader遷移、Offset越界、Broker宕機等)和Offset的維護都需要自行處理。 大家可以關注下不日發布的0.9 Release。開發人員又用Java重寫了一套Consumer。把兩套API合并在一起，同時去掉了對Zookeeper的依賴。據說效能有大幅度提升哦~~ 所有參數配置列表

broker預設參數及可配置所有參數列表：
http://blog.csdn.net/lizhitao/article/details/25667831

kafka原理、基本概念，broker，producer，consumer，topic所有參數配置列表
http://blog.csdn.net/suifeng3051/article/details/48053965 參考

http://bbs.umeng.com/thread-12479-1-1.html
http://www.jasongj.com/2015/01/02/Kafka%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90/

官方文檔：
http://kafka.apache.org/documentation.html#configuration