電商中有這樣的乙個場景：
下單成功之後送積分的操作，我們使用mq來實現
下單成功之後，投遞一條訊息到mq，積分系統消費訊息，給使用者增加積分
我們主要討論一下，下單及投遞訊息到mq的操作，如何實現？每種方式優缺點？
step1：start transaction
step2：生成訂單
step3：投遞訊息到mq
step4：commit transaction
這種方式是將傳送訊息放在了事務提交之前，可能存在的問題：
step3發生異常
導致step4失敗，下單失敗，直接影響到下單業務step4發生異常，其他step成功
下單失敗，訊息投遞成功，給使用者增加了積分我們將傳送訊息放到事務之後進行：
step1：start transaction
step2：生成訂單
step3：commit transaction
step4：投遞訊息到mq
可能會出現的問題:
step4發生異常，其他step成功
導致下單成功，投遞訊息失敗，使用者未增加積分上面兩種是比較常見的做法，也是最容易出錯的。
step1：start transaction
step2：生成訂單
step3：本地庫中插入一條需要傳送訊息的記錄t_msg_record
step3：commit transaction
step5：新增乙個定時器，輪詢t_msg_record，將待傳送的記錄投遞到mq中
這種方式借助了資料庫的事務，業務和訊息記錄作為了乙個原子操作，業務成功之後，訊息日誌必定是存在的。解決了前兩種方式遇到的問題。如果我們的業務系統比較單一，可以採用這種方式。
對於微服務化的情況，上面這種方式不是太好，每個服務都需要上面的操作；也不利於擴充套件。
增加乙個訊息服務及訊息庫，負責訊息的落庫、將訊息傳送投遞到mq。
step1：start transaction
step2：生成訂單
step3：當前事務庫插入一條日誌：生成乙個唯一的業務id（bus_id），將bus_id和訂單關聯起來儲存到當前事務所在的庫中
step4：呼叫訊息服務：攜帶bus_id，將訊息先落地入庫，此時訊息的狀態為待傳送狀態，返回訊息id(msg_id)
step5：commit transaction
step6：如果上面都成功，呼叫訊息服務，將訊息投遞到mq中；如果上面有失敗的情況，則呼叫訊息服務取消訊息的傳送
能想到上面這種方式，已經算是有很大進步了，我們繼續分析一下可能存在的問題：
系統中增加了乙個訊息服務，下單操作依賴於該服務，業務對改服務依賴性比較高，當訊息服務不可用時，整個業務將不可用。
若step6失敗，訊息將處於待傳送狀態，此時業務方需要提供乙個會查介面（通過bus_id查詢）,驗證業務是否執行成功；訊息服務需新增乙個定時任務，對於狀態為待傳送狀態的訊息做補償處理，檢查一下業務是否處理成功；從而確定訊息是投遞還是取消傳送
step4依賴於訊息服務，如果訊息服務效能不佳，會導致當前業務的事務提交時間延長，容易產生死鎖，並導致併發效能降低。我們通常是比較忌諱在事務中做遠端呼叫處理的，遠端呼叫的效能和時間往往不可控，會導致當前事務變為乙個大事務，從而引發其他故障。
在以上方式中，我們繼續改進，進而出現了更好的一種方式：
step1：生成乙個全域性唯一業務訊息id（bus_msg_id)，呼叫訊息服務，攜帶bus_msg_id，將訊息先落地入庫，此時訊息的狀態為待傳送狀態，返回訊息id（msg_id）
step2：start transaction
step3：生成訂單
step4：當前事務庫插入一條日誌（將step3中的業務和bus_msg_id關聯起來）
step5：commit transaction
step6：分2中情況：如果上面都成功，呼叫訊息服務，將訊息投遞到mq中；如果上面有失敗的情況，則呼叫訊息服務取消訊息的傳送
方式五和方式四對比，比較好的乙個地方：將呼叫訊息服務，訊息落地操作，放在了事務之外進行，這點小的改進其實算是乙個非常好的優化。
若我們的系統系統比較小比較單一簡單，建議採用方式三
若我們的系統採用微服務的方式，建議使用方式五
聊聊mq的使用場景
聊聊業務系統中投遞訊息到mq的幾種方式
如何確保投遞訊息一定成功？
聊聊訊息消費的幾種方式
如何確保訊息至少消費一次
如何保證訊息消費的冪等性
聊聊mq中訊息消費的幾種方式
對mq了解不是很多的，可以看一下下面兩篇文章 聊聊mq的使用場景 聊聊業務系統中投遞訊息到mq的幾種方式 聊聊訊息消費的幾種方式 如何確保訊息至少消費一次 如何保證訊息消費的冪等性 從消費者的角度出發，分析一下訊息消費的兩種方式 push方式 pull方式 mq接收到訊息 mq主動將訊息推送給消費者...
聊聊mq中訊息消費的幾種方式
對mq了解不是很多的，可以看一下下面兩篇文章 聊聊mq的使用場景 聊聊業務系統中投遞訊息到mq的幾種方式 聊聊訊息消費的幾種方式 如何確保訊息至少消費一次 如何保證訊息消費的冪等性 從消費者的角度出發，分析一下訊息消費的兩種方式 push方式 pull方式 mq接收到訊息 mq主動將訊息推送給消費者...
聊聊應用系統架構的0到1
沉迷於業務開發的你們，有沒有考慮過 使用者訪問到你開發的業務功能，到底經過了哪些環節 今天我將結合這些年的一些認知理解，開壇設法給大家講一講應用系統架構的從 0 到 1。01.如何造乙個大泥球？產品汪 緊急需求，2 天時間完成 x 的上線，包含知識問答頁面功能。程式猿 時間短，任務緊。一切以上線為目...