如果你已經瞭解了kafka的producer基礎理論，可以跳過這篇文章
Partition & Replicas
我創建了一個名爲producer-0的topic,partitions的數量爲3，每個partitions除了本身之外還有一個副本，如下圖。
Topic:producer-0 Partition:0 Leader:2 Replicas:2,1 Isr:2,1分析第二行，對於 partition:0，在broker id爲1,2的機器上各有一份，內容相同，這兩個partition中有一個leader，然後這個leader負責對外的讀寫，Leader:2表示broker id爲2的機器是leader。
在上一篇文章中，生產者的配置中有個
props.put("acks","all")的配置，將acks設置爲all，表示只有所有的副本都保存了生產者發送的消息後，才表示生產者發送成功。其本質是消息被髮送到leader後，其他的副本會從leader上增量複製，如果一個副本沒能與leader保持同步，那麼他將會從Isr列表中移除。
以上面爲例，如果機器1沒能及時的從機器2中同步消息，那麼Isr將會只有2了。
當ack=1，表示producer寫partition leader成功後，broker就返回成功，無論其他的partition follower是否寫成功。
當ack=2，表示producer寫partition leader和其他一個follower成功的時候，broker就返回成功，無論其他的partition follower是否寫成功。
如果ack=1的時候，一旦有個broker宕機導致partition的follower和leader切換，會導致丟數據
kafka消息傳輸的3種語義
（1）At most once 消息可能會丟，絕對不會重複傳輸；
（2）At least once 消息絕對不會丟，但是可能會重複傳輸；
（3）Exactly once 每條信息肯定會被傳輸一次且僅傳輸一次，這是用戶想要的。
at most once
消費者fetch消息,然後保存offset,然後處理消息;當client保存offset之後,但是在消息處理過程中consumer進程失效(crash),導致部分消息未能繼續處理.那麼此後可能其他consumer會接管,但是因爲offset已經提前保存,那麼新的consumer將不能fetch到offset之前的消息(儘管它們尚沒有被處理),這就是”at most once”.at least once
消費者fetch消息,然後處理消息,然後保存offset.如果消息處理成功之後,但是在保存offset階段zookeeper異常或者consumer失效,導致保存offset操作未能執行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的消息,這就是”at least once”.Exactly once
“Kafka Cluster”到消費者的場景中可以採取以下方案來得到“恰好1次”的一致性語義：
最少1次＋消費者的輸出中額外增加已處理消息最大編號：由於已處理消息最大編號的存在，不會出現重複處理消息的情況。
在實際應用中其實也很好實現，只需要保證消費接口的冪等性即可。比如，你收到一條訂單號爲101的付款成功的消息，此時你會將訂單狀態更新爲已付款狀態，由於At least once的存在，你可能再次收到這條消息，此時你只需要查詢數據庫中訂單的狀態，如果已經付款了，那麼這條消息可以忽略掉。所以很多時候，從業務層面上，其實是很容易實現Exactly once。
有一篇非常好的kafka文章： https://blog.csdn.net/ychenfeng/article/details/74980531