異步:例如在審批的場景中，需要在壹個流程中完成多個步驟。例如，審批通過/拒絕後，需要發送消息進行通知、處理事務和通知下遊系統。如果這些步驟是同步的，則整個調用鏈會太長，耗時太長，從而影響整體性能。因此，消息通知、代理和通知下遊的步驟可以異步處理。
解耦:如果多線程用於異步，將導致與下遊系統的耦合。對於每個系統，將添加壹個接口調用，然後重新發布系統。消息隊列用於將消息發布到消息隊列，下遊系統直接監控審批流程的消息感知審批進度，達到解耦的目的。
削峰:主要是應對突發流量對系統的沖擊，導致系統過載。消息隊列可以控制消耗速度，並根據系統的處理能力進行消耗，如秒殺系統。
Jms: Java消息服務
Jms是java消息服務的縮寫，jms客戶端可以使用jms服務進行異步消息傳輸。ActiveMQ是基於JMS規範實現的。
Jms支持兩種消息模型:
JMS的五種不同消息體格式:
AMQP:高級消息隊列協議。
對比度:
選擇需要綜合考慮:可靠性、性能、吞吐量、消息順序、消息是否會丟失等。
重復消費:如果消費者重復消費同壹條消息，將導致業務異常。為了解決這個問題，我們需要確保接口是冪等的，以消除重復消費帶來的問題。冪等意味著同壹操作執行多次，其影響與第壹次執行相同。
對於強驗證的場景，我們可以添加日記賬對賬表來確保冪等性，即日記賬對賬表用於記錄消費的消息。如果消息再次出現，首先比較是否有消耗的數據並直接返回。
對於弱檢查場景，可以進行緩存比較判斷。
順序消費:在同壹個場景中對多個消費者的多個消息進行順序消費的情況下，例如添加、修改和刪除操作，需要確保順序消費。或者審批流程的啟動、通過和結束消息需要嚴格排序。RocketMQ主題中的隊列機制可以保證FIFO，這是通過同步向同壹隊列發送消息來實現的。在這裏，只有有序的交付得到保證，有序的消費由消費者自己來保證。
分布式事務:事務是壹系列操作成功或回滾的保證。分布式事務是壹個系統，其中壹系列操作保證成功或失敗。
常見的分布式事務解決方案: