在上一章中[SpringBoot整合RabbitMQ](修改地址)，已經詳細介紹了訊息佇列的作用，這一種我們直接來學習SpringBoot如何整合kafka傳送訊息。 ## kafka簡介 kafka是用Scala和Java語言開發的，高吞吐量的分散式訊息中介軟體。高吞吐量使它在大資料領域具有天然的優勢，被廣泛用來記錄日誌。 ### kafka架構分析  注1：圖中的紅色箭頭表示訊息的流動過程，藍色表示分割槽備份，綠色表示kafka叢集註冊到zookeeper。 注2：在kafka0.9版本之前，消費者消費訊息的位置記錄在zookeeper中，在0.9版本之後，消費訊息的位置記錄在kafka的一個topic上。 **kafka名詞簡介**： 1. Producer：訊息生產者 2. Consumer：訊息消費者 3. Consumer Group（CG）：消費者組，一個topic可以有多個CG，每個Partition只會把訊息傳送給GG中的一個Consumer 4. Broker：一臺kafka伺服器就是一個broker，一個broker有多個topic 5. Topic：訊息主題，訊息分類，可看作佇列 6. Partition：分割槽，為了實現擴充套件，一個大的topic可能分佈到多個broker上，一個topic可以分為多個partition，partition中的每條訊息都會被分配一個有序的id（offset），每個partiton中的訊息是有序的。 7. Offset：kafka的儲存檔案都是按照offset.kafka來命名的，方便查詢，第一個offset為0000000000.kafka。 8. Leader：分割槽具有被備份，主分割槽 9. Follower：從分割槽 #### 1. 生產者分割槽策略 1. 指定分割槽。 2. 沒有指定分割槽但有key值，將key的hash值與當前topic的分割槽個數進行取餘得到分割槽。 3. 如果既沒有指定分割槽又沒有指定key，第一次呼叫時隨機生成一個整數（以後呼叫每次在這個整數上自增），將這個隨機數與該topic的分割槽數取餘得到分割槽。 #### 2. 訊息可靠性問題 採用ack確認機制來保證訊息的可靠性。 kafka在傳送訊息後會同步到其他分割槽副本，等所有副本都接收到訊息後，kafka才會傳送ack進行確認。採用這種模式的劣勢就是當其中一個副本宕機後，則訊息生產者就不會收到kafka的ack。 kafka採用**ISR**來解決這個問題。 **ISR**：Leader維護的一個和leader保持同步的follower集合。 當ISR中的folower完成資料同步之後，leader就會向follower傳送ack，如果follower長時間未向leader同步資料，則該follower就會被踢出ISR，該時間閥值的設定引數為`replica.lag.time.max.ms`，預設時間為10s，leader發生故障後，就會從ISR中選舉新的leader。 > 注：本文所講的kafka版本為0.11，在0.9版本以前成為ISR還有一個條件，就是同步訊息的條數。 **ack引數配置** 0：生產者不等待broker的ack。 1：leader分割槽接收到訊息向生產者傳送ack。 -1（all）：ISR中的leader和follower同步成功後，向生產者傳送ack。 #### 3. 訊息一致性問題 假如leader中有10條訊息，向兩個follower同步資料，follower A同步了8條，follower B同步了9條。這時候leader宕機了，follower A和follower B中的訊息是不一致的，剩下兩個follower就會重新選舉出一個leader。 - LEO（log end offset）：每個副本的最後一個offset - HW（high watermark）：所有副本中最小的offset 為了保證資料的一致性，所有的follower會將各自的log檔案**高出HW的部分**截掉，然後再從新的leader中同步資料。 #### 4. 訊息重複性問題 在kafka0.11版本中引入了一個新特性：冪等性。啟用冪等性後，ack預設為-1。將生產者中的`enable.idompotence`設定為true，即啟用了冪等性。 開啟冪等性的Producer在初始化的時候會被分配一個PID，發往同一Partition的訊息會附帶Sequence Number。Broker端會對