Kafka 無消息丟失的配置，每一個其實都能對應上面提到的問題。

1. 不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。記住，一定要使用帶有回調通知的 send 方法。

2. 設置 acks = all。acks 是 Producer 的一個參數，代表了你對“已提交”消息的定義。如果設置成 all，則表明所有副本 Broker 都要接收到消息，該消息纔算是“已提交”。這是最高等級的“已提交”定義。

3. 設置 retries 爲一個較大的值。這裏的 retries 同樣是 Producer 的參數，對應前面提到的 Producer 自動重試。當出現網絡的瞬時抖動時，消息發送可能會失敗，此時配置了 retries > 0 的 Producer 能夠自動重試消息發送，避免消息丟失。

4. 設置 unclean.leader.election.enable = false。這是 Broker 端的參數，它控制的是哪些 Broker 有資格競選分區的 Leader。如果一個 Broker 落後原先的 Leader 太多，那麼它一旦成爲新的 Leader，必然會造成消息的丟失。故一般都要將該參數設置成 false，即不允許這種情況的發生。

5. 設置 replication.factor >= 3。這也是 Broker 端的參數。其實這裏想表述的是，最好將消息多保存幾份，畢竟目前防止消息丟失的主要機制就是冗餘。

6. 設置 min.insync.replicas > 1。這依然是 Broker 端參數，控制的是消息至少要被寫入到多少個副本纔算是“已提交”。設置成大於 1 可以提升消息持久性。在實際環境中千萬不要使用默認值 1。

7. 確保 replication.factor > min.insync.replicas。如果兩者相等，那麼只要有一個副本掛機，整個分區就無法正常工作了。我們不僅要改善消息的持久性，防止數據丟失，還要在不降低可用性的基礎上完成。推薦設置成 replication.factor = min.insync.replicas + 1。

8. 確保消息消費完成再提交。Consumer 端有個參數 enable.auto.commit，最好把它設置成 false，並採用手動提交位移的方式。就像前面說的，這對於單 Consumer 多線程處理的場景而言是至關重要的。