如果消息正常投遞，消息進入隊列，這時候生產(chǎn)者的任務(wù)已經(jīng)完成，數(shù)據(jù)庫也會更新為投遞成功。

消費者出現(xiàn)問題，如果設(shè)置了消息正常消費后發(fā)送ack響應(yīng)，那么這個消息隊列不會收到ack響應(yīng)，所以不會從隊列中移除。當(dāng)消費者和broker斷開連接，該消息會重新變?yōu)閞eady狀態(tài)，等待新的消費者消費。

上面說錯了。生產(chǎn)者接受的ack來自broker，不是消費者。-.-

如果消費方出現(xiàn)問題，那么消費方不能發(fā)送ack響應(yīng)，那生產(chǎn)者會重復(fù)發(fā)送消息，這種場景下消費者也不會出現(xiàn)重復(fù)消費的問題。

生產(chǎn)者投遞消息后，接收到的ack是來自消費者。消費者可以設(shè)置消費完消息，再給生產(chǎn)者發(fā)送ack=true的響應(yīng)。

努力重試的過程需要對庫里的數(shù)據(jù)進行update動作，這個動作是根據(jù)上一次的MessageId來進行update，而不是insert動作，這時候的更新的只是order的狀態(tài)，以及努力次數(shù)，因此重復(fù)入庫的情況，也就是重復(fù)消費的情況不存在。

個人覺得看具體業(yè)務(wù)實現(xiàn)了，如果消費方出現(xiàn)異常，理論上你操作的業(yè)務(wù)表和日志表處于同一事物，也就是說最終沒能更新發(fā)送狀態(tài)，也沒能消費成功，這個時候走定時任務(wù)，然后發(fā)送(二次投遞)-->再次消費。

如果說由于網(wǎng)絡(luò)原因，你消費成功了，然后服務(wù)得到失敗的結(jié)果，而恰好你有重試策略(當(dāng)然很多業(yè)務(wù)場景都需要設(shè)置這個策略),再次發(fā)送了，那么必然導(dǎo)致數(shù)據(jù)重復(fù)消費。這個時候就靠你消費者具體的設(shè)計了，防止重復(fù)消費，做冪等處理。