Kafka中的消息是否會丟失和重複消費（轉）

在以前的基礎上，基本搞清楚了Kafka的機制及如何運用。這裏思考一下：Kafka中的消息會不會丟失或重複消費呢？爲何呢？

        要肯定Kafka的消息是否丟失或重複，從兩個方面分析入手：消息發送和消息消費

一、消息發送

         Kafka消息發送有兩種方式：同步（sync）和異步（async），默認是同步方式，可經過producer.type屬性進行配置。Kafka經過配置request.required.acks屬性來確認消息的生產：

0---表示不進行消息接收是否成功的確認；

1---表示當Leader接收成功時確認；

-1---表示Leader和Follower都接收成功時確認；

綜上所述，有6種消息生產的狀況，下面分狀況來分析消息丟失的場景：

（1）acks=0，不和Kafka集羣進行消息接收確認，則當網絡異常、緩衝區滿了等狀況時，消息可能丟失；

（2）acks=一、同步模式下，只有Leader確認接收成功後但掛掉了，副本沒有同步，數據可能丟失；

二、消息消費

        Kafka消息消費有兩個consumer接口，Low-level API和High-level API：

Low-level API：消費者本身維護offset等值，能夠實現對Kafka的徹底控制；

High-level API：封裝了對parition和offset的管理，使用簡單；

若是使用高級接口High-level API，可能存在一個問題就是當消息消費者從集羣中把消息取出來、並提交了新的消息offset值後，還沒來得及消費就掛掉了，那麼下次再消費時以前沒消費成功的消息就「詭異」的消失了；    

解決辦法：

        針對消息丟失：同步模式下，確認機制設置爲-1，即讓消息寫入Leader和Follower以後再確認消息發送成功；異步模式下，爲防止緩衝區滿，能夠在配置文件設置不限制阻塞超時時間，當緩衝區滿時讓生產者一直處於阻塞狀態；

        針對消息重複：將消息的惟一標識保存到外部介質中，每次消費時判斷是否處理過便可。

        

Kafka的Leader選舉機制

        Kafka將每一個Topic進行分區Patition，以提升消息的並行處理，同時爲保證高可用性，每一個分區都有必定數量的副本 Replica，這樣當部分服務器不可用時副本所在服務器就能夠接替上來，保證系統可用性。在Leader上負責讀寫，Follower負責數據的同步。當一個Leader發生故障如何從Follower中選擇新Leader呢？

        Kafka在Zookeeper上針對每一個Topic都維護了一個ISR（in-sync replica---已同步的副本）的集合，集合的增減Kafka都會更新該記錄。若是某分區的Leader不可用，Kafka就從ISR集合中選擇一個副本做爲新的Leader。這樣就能夠容忍的失敗數比較高，假如某Topic有N+1個副本，則能夠容忍N個服務器不可用。

        若是ISR中副本都不可用，有兩種處理方法：

（1）等待ISR集合中副本復活後選擇一個可用的副本；

（2）選擇集羣中其餘可用副本；

具體可參考：http://www.jasongj.com/2015/04/24/KafkaColumn2/————————————————版權聲明：本文爲CSDN博主「行者小朱」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/u012050154/article/details/78592854