如果消息正常投遞，消息進入隊列，這時候生產者的任務已經完成，數據庫也會更新為投遞成功。

消費者出現問題，如果設置了消息正常消費后發送ack響應，那么這個消息隊列不會收到ack響應，所以不會從隊列中移除。當消費者和broker斷開連接，該消息會重新變為ready狀態，等待新的消費者消費。

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

如果消費方出現問題，那么消費方不能發送ack響應，那生產者會重復發送消息，這種場景下消費者也不會出現重復消費的問題。

生產者投遞消息后，接收到的ack是來自消費者。消費者可以設置消費完消息，再給生產者發送ack=true的響應。

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

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

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