在之前的基礎上，基本搞清楚了Kafka的機制及如何運用。這里思考一下：Kafka中的消息會不會丟失或重復消費呢？為什么呢？
要確定Kafka的消息是否丟失或重復，從兩個方面分析入手：消息發送和消息消費
1、消息發送
Kafka消息發送有兩種方式：同步（sync）和異步（async），默認是同步方式，可通過producer.type屬性進行配置。Kafka通過配置request.required.acks屬性來確認消息的生產：
0---表示不進行消息接收是否成功的確認；
1---表示當Leader接收成功時確認；
-1---表示Leader和Follower都接收成功時確認；
綜上所述，有6種消息生產的情況，下面分情況來分析消息丟失的場景：
（1）acks=0，不和Kafka集群進行消息接收確認，則當網絡異常、緩沖區滿了等情況時，消息可能丟失；
（2）acks=1、同步模式下，只有Leader確認接收成功后但掛掉了，副本沒有同步，數據可能丟失；
2、消息消費
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
原文：https://blog.csdn.net/u012050154/article/details/78592854
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！