有了多副本，Kafka還是可能丟消息，業(yè)務(wù)系統(tǒng)怎么辦？？

消息中間件丟消息的場(chǎng)景非常多，因?yàn)槭褂蒙系牟缓侠韺?dǎo)致的，都很容易解決，比如下面這些：

（1）異步發(fā)送。消息在客戶端端內(nèi)存里面，重啟丟失。

（2）同步發(fā)送，ACK = 1。Broker發(fā)生了主從切換，丟消息。

（3）消費(fèi)方拉取消息之后就ACK，消息還在內(nèi)存里面，沒來(lái)得及處理完，掛了重啟。

（4）早期的Kafka版本，因?yàn)橹鲝膹?fù)制算法有缺陷，主從來(lái)回切換，可能丟消息。后來(lái)改成了類似Raft的epoch機(jī)制，沒有了此問題。

即使所有這些統(tǒng)統(tǒng)都避免了，但因?yàn)槿粘＿\(yùn)維問題，導(dǎo)致極小概率的消息丟失偶爾發(fā)生。

作為業(yè)務(wù)系統(tǒng)，沒辦法完全信任消息中間件的可靠性，但業(yè)務(wù)又要求一個(gè)不能丟，怎么處理呢？

答案是：業(yè)務(wù)ACK。

系統(tǒng)A給系統(tǒng)B發(fā)的消息，在系統(tǒng)B沒有給系統(tǒng)A發(fā)送ACK之前，系統(tǒng)A的消息在自己的DB里面暫存一份。接受到ACK之后，刪除DB消息；超過(guò)一定時(shí)間，收不到ACK，這些消息重發(fā)，直到所有消息都最終刪除。

這個(gè)ACK，有多種實(shí)現(xiàn)方式：可以是系統(tǒng)A提供一個(gè)ACK接口供B調(diào)用，也可以是再準(zhǔn)備一個(gè)ACK隊(duì)列，系統(tǒng)B發(fā)送ACK消息，系統(tǒng)A消費(fèi)ACK消息。ACK消息丟了也不怕，大不了超時(shí)沒有ACK，系統(tǒng)A重新發(fā)送，B重新消費(fèi)（顯然，B必須冪等）。

學(xué)過(guò)TCP原理的應(yīng)該會(huì)發(fā)現(xiàn)：這個(gè)ACK + 超時(shí)重傳機(jī)制，和TCP實(shí)現(xiàn)可靠傳輸?shù)脑硎钱惽ぁ?/span>把消息中間件類比UDP（不可靠的，可能丟消息），把業(yè)務(wù)系統(tǒng)類比TCP（可靠的，不丟不重），在一個(gè)不可靠的傳輸通道上實(shí)現(xiàn)了可靠的消息傳輸。