kafka性能調優解密（三）-- Consumer端

Consumer篇

1? fetch.message.max.bytes

這個參數是Consumer每次發起獲取消息請求的時候，會發往給broker端指導broker端每次讀取partition日志時的最大消息長度。這個值越大有利于減少日志讀取的次數，提升broker端獲取數據的速度，但越大占的內存也越大。在讀取數據時，BoundedByteBufferReceive.readFrom用來申請讀取緩存的總大小（byteBufferAllocate）， 同時這個設置是針對每個分區的，即共需要的內存為fetch.size * partitionNum

1.3 實測分析

1.?個broker 創建10個分區的topic

2.?同時啟動Producer與Consumer，一起測試

3.?測試Consumer scoket.receiver.buffer.bytes取值為256k 或者2M， 這兩者在不同fetch.message.max.bytes的區別

10G網卡下，10分區，2k數據，發送1000000, ack都為1, N個Producer與N個Consumer一起跑, Consumer每次從隊列開始讀取數據，10個線程， bufferMemory為32M, Producer默認send buf為128k：

10分區，4k數據，發送1000000, ack都為1, N個Producer與N個Consumer一起跑, Consumer每次從隊列開始讀取數據，10個線程， bufferMemory為32M, Producer默認send buf為128k:

可以看出無論是2k或者4k數據，fetch.size在1M~8M之間，Consumer性能都是在峰值范圍

結論：

1. 需要根據業務最大消息來配置，比如業務最大4M， 這個參數至少配置4M

2. 實測證明，在內存足夠的情況下，也不是越大越好。從目前來看1M~8M性能都穩定在峰值附近

2?num.consumer.fetchers

該參數是用于指定Consumer端用于fetcht數據的線程數(fetch threads)，如下圖：

Consumer跟根據這個線程個數和Topic的分區數，均勻地分布在這些fetch threads上。增大這些線程能起到一定的提升性能，但是多于分區個數后，就會有線程空閑。

2.3 實測分析

1.?2個broker 創建10個分區的topic

2.?同時啟動Producer與Consumer，一起測試

3.?通過指定Consumer不同的fetch threads,查看性能結果

10G網卡下，10分區，2k數據，發送1000000, ack都為1, 10個Producer與10個Consumer一起跑, Consumer每次從隊列開始讀取數據，bufferMemory為32M：

結論：

1.?從性能上看，10個Consumer線程配10個Fetch 線程，性能最優

2.?10個Fetch線程后面就會有空閑的線程分配不到partition

3? offsets.storage

Kafka會記錄offset到zk中。但是，zk client api對zk的頻繁寫入是一個低效的操作。0.8.2 kafka引入了native offset storage，將offset管理從zk移出，并且可以做到水平擴展。其原理就是利用了kafka的compacted topic，offset以consumer group,topic與partion的組合作為key直接提交到compacted topic中。同時Kafka又在內存中維護了的三元組來維護最新的offset信息，consumer來取最新offset信息的時候直接內存里拿即可。當然，kafka允許你快速的checkpoint最新的offset信息到磁盤上。

3.3 實測分析

1.?2個broker 創建10個分區的topic

2.?同時啟動Producer與Consumer，一起測試

3.?在不同的壓力下， 查看offsets.storage保存在zk上性能好還是broker上好

10G網卡下，10分區，2k數據，發送1000000, ack都為1, N個Producer與N個Consumer一起跑, Consumer每次從隊列開始讀取數據，10個線程， bufferMemory為32M, Consumer receiver buffer大小為2M:

從上面的數據來看，存儲在zookeeper與存儲在kafka，性能峰值相差不

結論：

1.在broker節點數不是很多并且對zk節點寫入不大的情況下，這個選項對性能影響不是很大，但以后社區會推用存儲在kafka，為了避免以后修改，建議值為kafka

尾聲

性能相關的核心參數詳解到處就結束了，希望對大家業務應用有幫助。對于應用PUMA或者kafka作為消息總線的用戶，應該在實施過程關注過這樣的問題：具體業務不同可靠模式下，對于特定硬件及網絡，需要多少資源，才能達到業務需要的吞吐量。這個PUMA經過大量實踐驗證及理論分析，證明可以通過簡單測試及公式計算就可以完成業務資源部署評估，相關進一步信息歡迎聯系PUMA或持續關注后續的解密，謝謝~

Kafka 應用性能調優

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