在之前的基礎上，基本搞清楚了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）選擇叢集中其他可用副本；