Producer:
- block.on.buffer.full = true 儘管該參數在0.9.0.0已經被標記爲“deprecated”，但鑑於它的含義非常直觀，所以這裏還是顯式設置它爲true，使得producer將一直等待緩衝區直至其變爲可用。否則如果producer生產速度過快耗盡了緩衝區，producer將拋出異常
- acks=all 很好理解，所有follower都響應了才認爲消息提交成功，即"committed"
- retries = MAX 無限重試，直到你意識到出現了問題:)
max.in.flight.requests.per.connection= 1 限制客戶端在單個連接上能夠發送的未響應請求的個數。設置此值是1表示kafka broker在響應請求之前client不能再向同一個broker發送請求。注意：設置此參數是爲了避免消息亂序- 使用KafkaProducer.send(record, callback)而不是send(record)方法 自定義回調邏輯處理消息發送失敗
- Callback邏輯中最好顯式關閉
KafkaProducer.close(0)，設置此參數是爲了避免消息亂序，在Callback的失敗處理邏輯中顯式調用KafkaProducer.close(0),這樣做的目的是爲了處理消息的亂序問題。若不使用close(0)，默認情況下producer會將未完成的消息發送出去，這樣就可能造成消息亂序。
Broker:
- unclean.leader.election.enable=false 關閉unclean leader選舉，即不允許非ISR中的副本被選舉爲leader，以避免數據丟失
- replication.factor >= 3 這個完全是個人建議了，參考了Hadoop及業界通用的三備份原則
- min.insync.replicas > 1 消息至少要被寫入到這麼多副本纔算成功，也是提升數據持久性的一個參數。與acks配合使用
- 保證replication.factor > min.insync.replicas 如果兩者相等，當一個副本掛掉了分區也就沒法正常工作了。通常設置replication.factor = min.insync.replicas + 1即可
Consumer:
- enable.auto.commit=false 關閉自動提交位移
- 在消息被完整處理之後再手動提交位移