kafka生產者Producer參數設置及參數調優建議-kafka 商業環境實戰

kafka商業環境實戰系列

本套系列博客從真實商業環境抽取案例進行總結和分享，並給出kafka商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。版權聲明：本套kafka調優系列版權歸做者(秦凱新)全部，禁止轉載，歡迎學習。

做者：秦凱新 地址：於深圳

• kafka 商業環境實戰-kafka生產環境規劃
• kafka 商業環境實戰-kafka生產者和消費者吞吐量測試
• kafka 商業環境實戰-kafka生產者Producer參數設置及參數調優建議

1. Producer核心工做流程

• Producer首先使用用戶主線程將待發送的消息封裝進一個ProducerRecord類實例中。
• 進行序列化後，發送給Partioner，由Partioner肯定目標分區後，發送到Producer程序中的一塊內存緩衝區中。
• Producer的另外一個工做線程（即Sender線程），則負責實時地從該緩衝區中提取出準備好的消息封裝到一個批次的內，統一發送給對應的broker中。

2. producer 主要參數設置

2.1 producer 參數acks 設置（無數據丟失）

在消息被認爲是「已提交」以前，producer須要leader確認的produce請求的應答數。該參數用於控制消息的持久性，目前提供了3個取值：

acks = 0: 表示produce請求當即返回，不須要等待leader的任何確認。這種方案有最高的吞吐率，可是不保證消息是否真的發送成功。

acks = -1: 表示分區leader必須等待消息被成功寫入到全部的ISR副本(同步副本)中才認爲produce請求成功。這種方案提供最高的消息持久性保證，可是理論上吞吐率也是最差的。

acks = 1: 表示leader副本必須應答此produce請求並寫入消息到本地日誌，以後produce請求被認爲成功。若是此時leader副本應答請求以後掛掉了，消息會丟失。這是個這種的方案，提供了不錯的持久性保證和吞吐。

商業環境推薦：

若是要較高的持久性要求以及無數據丟失的需求，設置acks = -1。其餘狀況下設置acks = 1

2.2 producer參數 buffer.memory 設置（吞吐量）

該參數用於指定Producer端用於緩存消息的緩衝區大小，單位爲字節，默認值爲：33554432合計爲32M。kafka採用的是異步發送的消息架構，prducer啓動時會首先建立一塊內存緩衝區用於保存待發送的消息，而後由一個專屬線程負責從緩衝區讀取消息進行真正的發送。

商業環境推薦：

• 消息持續發送過程當中，當緩衝區被填滿後，producer當即進入阻塞狀態直到空閒內存被釋放出來，這段時間不能超過max.blocks.ms設置的值，一旦超過，producer則會拋出TimeoutException 異常，由於Producer是線程安全的，若一直報TimeoutException，須要考慮調高buffer.memory 了。
• 用戶在使用多個線程共享kafka producer時，很容易把 buffer.memory 打滿。

2.3 producer參數 compression.type 設置（lZ4）

producer壓縮器，目前支持none（不壓縮），gzip，snappy和lz4。

商業環境推薦：

基於公司物聯網平臺，試驗過目前lz4的效果最好。固然2016年8月，FaceBook開源了Ztandard。官網測試： Ztandard壓縮率爲2。8，snappy爲2.091，LZ4 爲2.101 。

2.4 producer參數 retries設置(注意消息亂序,EOS)

producer重試的次數設置。重試時producer會從新發送以前因爲瞬時緣由出現失敗的消息。瞬時失敗的緣由可能包括：元數據信息失效、副本數量不足、超時、位移越界或未知分區等。假若設置了retries > 0，那麼這些狀況下producer會嘗試重試。

商業環境推薦：

• producer還有個參數：max.in.flight.requests.per.connection。若是設置該參數大約1，那麼設置retries就有可能形成發送消息的亂序。
• 版本爲0.11.1.0的kafka已經支持"精確到一次的語義」，所以消息的重試不會形成消息的重複發送。

2.5 producer參數batch.size設置(吞吐量和延時性能)

producer都是按照batch進行發送的，所以batch大小的選擇對於producer性能相當重要。producer會把發往同一分區的多條消息封裝進一個batch中，當batch滿了後，producer纔會把消息發送出去。可是也不必定等到滿了，這和另一個參數linger.ms有關。默認值爲16K，合計爲16384.

商業環境推薦：

• batch 越小，producer的吞吐量越低，越大，吞吐量越大。

2.6 producer參數linger.ms設置(吞吐量和延時性能)

producer是按照batch進行發送的，可是還要看linger.ms的值，默認是0，表示不作停留。這種狀況下，可能有的batch中沒有包含足夠多的produce請求就被髮送出去了，形成了大量的小batch，給網絡IO帶來的極大的壓力。

商業環境推薦：

• 爲了減小了網絡IO，提高了總體的TPS。假設設置linger.ms=5，表示producer請求可能會延時5ms纔會被髮送。

2.7 producer參數max.in.flight.requests.per.connection設置(吞吐量和延時性能)

producer的IO線程在單個Socket鏈接上可以發送未應答produce請求的最大數量。增長此值應該能夠增長IO線程的吞吐量，從而總體上提高producer的性能。不過就像以前說的若是開啓了重試機制，那麼設置該參數大於1的話有可能形成消息的亂序。

商業環境推薦：

• 默認值5是一個比較好的起始點,若是發現producer的瓶頸在IO線程，同時各個broker端負載不高，那麼能夠嘗試適當增長該值.
• 過大增長該參數會形成producer的總體內存負擔，同時還可能形成沒必要要的鎖競爭反而會下降TPS

結語

秦凱新 於深圳 2018-10-27