1 背景

在讀完kafka官方文檔，kafka設計里的消息交付語義一章后，給我的第一印象是內容很抽象，于是草擬和總結了給個副標題，并把相關內容進行了歸類；有些生澀的句子，盡量用大白話和舉例進行說明，并加入了總結。

消息交付語義的級別有哪些？

消息交付，即消息在生產端，broker端，消費者端的傳遞保證。

最多一次——消息可能會丟失，但永遠不會重新傳送。
至少一次——消息永遠不會丟失，但可以重新傳送。
恰好一次——這就是人們真正想要的，每條消息都傳遞一次且僅一次。

kafka 支持哪些消息交付語義？

根據英文文檔，進行了總結

###################以下為個人觀點###################

kafka 真的支持了 最少一次 的交付語義嗎？

我的回答是：不同的條件下，可能支持了，也可能沒支持。

kafka支持最少一次交付的前提條件

生產端：
kafka生產端在發送消息時，如果遇到底層網絡問題，可能會導致消息發送給了broker端，也有可能網絡閃斷或者丟包，發送的消息可能丟了；但最后的結果是，生產端會根據指定的參數retries，進行一定次數的重試。以此來保證生產端，做到消息至少傳遞一次。即發送失敗了，就重試吧。

所以生產端 支持"最少一次"的前提條件 有如下：

生產端的應用在重試的時候，沒有重啟，或者宕機

網絡，或者broker端，需要在生產端重試次數用完之前恢復

消費者端：
消費者端保證消息至少被消費一次的建議是：在消費者端消費完消息后，在手工提交offset；偽代碼如下：

while(true){ 
consumer.poll(); 
XXX 
consumer.commit();
}

具體原因和說明見：juejin.cn/post/729328…

broker端：
broker端，要實現此交付，主要是保證消息不丟。kafka 數據是具備高可靠的，但不代表你的kafka集群就具備了此功能。需要有如下配置：

第一：生產端參數ack 設置為all

第二：在broker端 配置min.insync.replicas參數設置至少為2

第三：在broker端配置replicator.factor參數至少3

第四：在broker端配置 unclean.leader.election.enable 參數建議設置為false

具體原因和說明見：juejin.cn/post/729328…

不支持的情況下，如何去保證消息交付最少一次的保證

消費者端和broker端，可以根據配置和對應代碼編寫順序進行解決；但生產端在進行重試時，還需依賴生產端應用的穩定性，底層網絡和broker端的可用性；

生產端之所以需要這三個條件的支持，還是生產端沒有把待發送消息進行持久化，畢竟待發送的消息是保存在jvm內存中的，jvm重啟或者OOM或者宕機了，內存中的消息也就丟了；
如果把待發送的消息進行了持久化，即使應用宕機，網絡失敗，broker不可用，但在經過應用重啟，網絡和broker恢復，也可以保證待發送消息不丟失，做到消息的至少一次交付。

審核編輯：湯梓紅