生產者
1、batch.size：默認是16384byte,也就是16kb，生產者發送多個消息到broker上的同一個分區時，爲了減少網絡請求帶來的性能開銷，通過批量的方式 來提交消息，可以通過這個參數來控制批量提交的字節數大小， 意味着當一批消息大小達到指定的batch.size的時候會統一發送。
2、linger.ms：默認0毫秒是立即發送，配置後會把兩次發送時間間隔內收集到的所有Requests進行一次聚合然後再發送，以此提高吞吐量，而linger.ms就是爲每次發送到broker的請求增加一些delay，以此來聚合更多的Message請求。
batch.size 和 linger.ms的作用是一樣的，當二者都配置的時候，只要滿足其中一個要求，就會發送請求到broker上。
消費者
1、max.poll.records：默認500條，限制每次調用poll返回的消息數，如果一次拉取太多消息在max.poll.interval.ms默認300秒內沒有處理完就會被認爲失敗，然後重新rebalance再次發送消息。
2、max.poll.interval.ms：默認300秒，如果在該時間內沒有處理完就會被認爲失敗，然後重新rebalance導致消息重複消費。
2、enable.auto.commit：默認是true，消費者消費消息以後自動提交，只有當消息提交以後，該消息纔不會被再次接收到，爲true時還可以配合 auto.commit.interval.ms控制自動提交的頻率，默認5秒。 也可以通過consumer.commitSync()的方式實現手動提交。
消息堆積
產生消息堆積的原因可能是消息發送的速率遠遠大於消息消費的速率，或者是消費者出現問題無法消費。
當消息發送的速率遠遠大於消息消費的速率時，可以考慮topic分區來增加消費者數量，或者消費者使用多線程，還有一點要注意是如果有入庫操作注意數據庫IO是否跟得上。
消費者出現問題無法消費要排查代碼，或者可以部署多個消費者，這裏要注意了一個topic分區只能被一個消費者消費，一個消費者可以消費多個topic分區，比如topic只有一個分區，卻有3個消費者，這樣其中兩個消費者會閒置起來造成資源浪費，比例最好爲1:1。
kafka配置信息：http://kafka.apache.org/23/documentation.html#configuration