Kafka關鍵參數設置

　　生產環境中使用Kafka，參數調優非常重要，而Kafka參數眾多，我們的java的Configuration代碼中，經常設置的參數如下：

Properties props = new Properties();

props.put("bootstrap.servers", "localhost:9092");

props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");

props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

props.put("buffer.memory", 67108864);

props.put("batch.size", 131072);

props.put("linger.ms", 100);

props.put("max.request.size", 10485760);

props.put("retries", 10);

props.put("retry.backoff.ms", 500);

props.put("acks", "1"); 

KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);

 

• buffer.memory

　　Kafka的客戶端發送數據到服務器，不是來一條就發一條，而是經過緩沖的，也就是說，通過KafkaProducer發送出去的消息都是先進入到客戶端本地的內存緩沖里，然后把很多消息收集成一個一個的Batch，再發送到Broker上去的，這樣性能才可能高。

　　buffer.memory的本質就是用來約束KafkaProducer能夠使用的內存緩沖的大小的，默認值32MB。

　　如果buffer.memory設置的太小，可能導致的問題是：消息快速的寫入內存緩沖里，但Sender線程來不及把Request發送到Kafka服務器，會造成內存緩沖很快就被寫滿。而一旦被寫滿，就會阻塞用戶線程，不讓繼續往Kafka寫消息了。 

　　所以“buffer.memory”參數需要結合實際業務情況壓測，需要測算在生產環境中用戶線程會以每秒多少消息的頻率來寫入內存緩沖。經過壓測，調試出來一個合理值。

 

• batch.size

　　每個Batch要存放batch.size大小的數據后，才可以發送出去。比如說batch.size默認值是16KB，那么里面湊夠16KB的數據才會發送。

  理論上來說，提升batch.size的大小，可以允許更多的數據緩沖在里面，那么一次Request發送出去的數據量就更多了，這樣吞吐量可能會有所提升。

　　但是batch.size也不能過大，要是數據老是緩沖在Batch里遲遲不發送出去，那么發送消息的延遲就會很高。

　　一般可以嘗試把這個參數調節大些，利用生產環境發消息負載測試一下。

 

• linger.ms

　　一個Batch被創建之后，最多過多久，不管這個Batch有沒有寫滿，都必須發送出去了。

　　比如說batch.size是16KB，但是現在某個低峰時間段，發送消息量很小。這會導致可能Batch被創建之后，有消息進來，但是遲遲無法湊夠16KB，難道此時就一直等着嗎？

　　當然不是，假設設置“linger.ms”是50ms，那么只要這個Batch從創建開始到現在已經過了50ms了，哪怕他還沒滿16KB，也會被發送出去。 

　　所以“linger.ms”決定了消息一旦寫入一個Batch，最多等待這么多時間，他一定會跟着Batch一起發送出去。 

　　linger.ms配合batch.size一起來設置，可避免一個Batch遲遲湊不滿，導致消息一直積壓在內存里發送不出去的情況。

  

• max.request.size

　　決定了每次發送給Kafka服務器請求消息的最大大小。

　　如果發送的消息都是大報文消息，每條消息都是數據較大，例如一條消息可能要20KB。此時batch.size需要調大些，比如設置512KB，buffer.memory也需要調大些，比如設置128MB。 

　　只有這樣，才能在大消息的場景下，還能使用Batch打包多條消息的機制。

　　此時“max.request.size”也得同步增加。

 

• retries和retries.backoff.ms

　　重試機制，也就是如果一個請求失敗了可以重試幾次，每次重試的間隔是多少毫秒，根據業務場景需要設置。

 

• acks

acks	含義
0	Producer 往集群發送數據不需要等到集群的返回，不確保消息發送成功。安全性最低但是效率最高。
1	Producer 往集群發送數據只要 Leader 應答就可以發送下一條，只確保 Leader 接收成功。
-1 或 all	Producer 往集群發送數據需要所有的ISR Follower 都完成從 Leader 的同步才會發送下一條，確保 Leader 發送成功和所有的副本都成功接收。安全性最高，但是效率最低。