消息隊列 - 關於消息隊列的消息丟失問題的一點思考
使用消息中間件必須面對的兩大問題 - 消息丟失 和 消息重復。
消息丟失的解決辦法主要是通過消息重發的補償手段，消息重發后導致消息重復，消息重復需要使用冪等解決。
消息從生產到消費，一般需要通過如圖3個階段。成熟的消息中間件的設計者都會考慮這個問題。rabbitmq在生產階段，一般會有回調確認機制，存儲階段，會有持久化配置策略，消費階段會有成功消費后的確認機制。spring 在封裝rabbitmq時，默認的配置策略很人性化，存儲階段默認配置成持久化，消費階段默認沒有異常后再向mq確認成功消費。
問題在於是否在生產消息時要人為保證百分之一百確保消息成功？因為即時使用了回調機制，重試策略，在極端情況下還是會丟失消息的。
如果要保證百分之一百成功，需要引入數據庫，設計上比較復雜， (參考學習資料)
如果每次使用消息中間件，都保證百分之一百成功，整體系統會越來越復雜。
因此，在核心重要業務上，如金錢相關的業務，就一定要保證百分之一百，
在非核心業務上，可以使用簡單的重試策略，重試幾次，發送數據，防止網絡導致的消息丟失。
重點在於，一定要先保證業務數據(如訂單數據)入庫成功，再去發送消息到mq供其他消費者消費。
這樣即時發送消息到mq時丟失了，也可以事后查庫補發。
如果有錯誤，歡迎斧正。