# Kafka 無消息丟失配置 Q * Kafka 里什么算消息丟失？ * 什么配置能保證消息不丟失？ A * Kafka 只對"已提交"的消息（committed message）做有限度的持久化保證。 --- * 已提交的消息 * Kafka 的若干 Broker 成功接收到一條消息并寫入日志文件后，告訴 Producer 消息已成功提交。此時為“已提交“消息。 * 有限度的持久化保證 * 假如消息保存在 N 個 Broker，至少有一個存活，即不會丟失。 ## 消息丟失案例 ### Producer 丟失數據 * 背景 * Kafka Producer 是異步發送消息 * 如果調用的是 `producer.send(msg)`，則會立即返回，但此時不能認為消息發送成功 * 這種方式稱為 `fire and forget` * 解決 * Producer 永遠要使用帶有回調通知的發送 API * 因此要使用 `producer.send(msg, callback)` ### Consumer 丟失數據 * 背景 * Consumer 有位移概念  * 如果提前更新位移，而未消費完，則會丟失 * 解決 * 保證先消費消息，再更新位移 * 這種辦法帶來的問題是消息的重復處理 ### Consumer 另一種丟失數據 * 背景 * Consumer 從 Kafka 獲取到消息后開啟多個線程異步處理 * Consumer 自動地向前更新 offset * 如果某個線程失敗，則該線程上消息丟失 * 解決 * 如果多線程異步處理消費信息，Consumer 程序不要開啟自動提交位移，而是應用程序手動提交 offset * 此種處理可能出現消息被多次消費 ### 一個隱秘的消息丟失場景 * 增加 Topic Partition * 在某段不巧的時間間隔后，Producer 先于 Consumer 感知到新增加的 Partition * 此時 Consumer 設置的是從最新位移處開始讀取消息 * 因此在 Consumer 感知到新分區前，Producer 發送的這些消息就全部丟失了 ## 最佳實踐 * 不要使用 `producer.send(msg)`，而是 `producer.send(msg, callback)` * 設置 acks = all * acks 是 Producer 的一個參數，代表了你對“已提交“消息的定義。 * 如果設置為 all，表明所有副本 Broker 都要接收到消息，才算“已提交“。這是最嚴謹的定義。 * 設置 retries 為一個較大的值 * retries 是 Producer 的參數，能夠讓 Producer 自動重試 * 設置 unclean.leader.election.enable = false * 這是 Broker 端參數，控制哪些 Broker 有資格競選分區的 Leader。 * 如果一個 Broker 落后原先的 Leader 太多，那么它一旦是新的 Leader，則會造成消息丟失。 * 設置 replicationn.factor >= 3 * Broker 端參數 * 最好將消息多保存幾份 * 設置 min.insync.replicas > 1 * Broker 端參數 * 控制的是消息至少要被寫入到幾個副本才算“已提交“ * 生產環境要設置大于 1 * 確保 replication.factor > min.insync.replicas * 如果兩者相等，只要有一個副本掛機，整個分區無法正常工作 * 推薦配置 replication.factor = min.insync.replicas + 1 * 確保消息消費完再提交 * Consumer 端參數 enable.auto.commit 設置成 false，采用手動提交位移 * 這對于單 Consumer 多線程處理很重要