消息隊列使用的場景： 異步、解耦、削峰
異步： 比如在審批的場景裏，多個步驟需要在壹個流程裏做完，比如審批通過/拒絕後，需要發送消息通知、代辦、以及通知下遊系統。如果這些步驟同步完進行，整個調用鏈太長，耗時太長，影響整體性能。因此可以將消息通知、代辦和通知下遊這些步驟進行異步處理。
解耦： 如果使用多線程進行異步，這樣會造成與下遊系統耦合，每對接壹個系統，會增加壹個接口調用，然後重新發布系統。使用消息隊列，將消息發布到消息隊列中，下遊系統直接監聽審批過程消息來感知審批進度，達到解耦目的。
削峰： 主要是應對突然爆發的流量沖擊系統，導致系統超載。消息隊列可以控制消費速度，按照系統的處理能力進行消費，例如秒殺系統。
JMS： JAVA Message Service, java 消息服務
jms 是 java 消息服務的縮寫，jms 客戶端之間可以使用 jms 服務進行異步消息傳輸。ActiveMQ 就是基於 JMS 規範實現的。
jms 支持兩種消息模型：
JMS 五種不同的消息正文格式：
AMQP： Advanced Message Queuing Protocol，高級消息隊列協議
對比：
選型是需要綜合考慮：可靠性、性能、吞吐量、消息有序性、是否會丟失消息等
重復消費： 消費者集群如果重復消費同壹條消息會導致業務異常，為了解決這個問題，我們需要保證接口冪等來消除重復消費引起的問題，冪等即在多次執行相同操作，產生的影響與第壹次執行相同。
對於強校驗的場景，我們可以加流水對賬表來保證冪等性，即用流水對賬表記錄被消費的消息，如果再次來消息，先對比有沒有被消費過，消費過的數據，直接返回。
對於弱校驗場景，可以做緩存對比判斷。
順序消費： 對於同壹個場景中多個消費者多條消息需要進行順序消費的情況下，例如增改刪操作需要保證順序消費。或者審批流程的發起、通過、結束消息需要嚴格保證順序。RocketMQ topic 內的隊列機制可以保證 FIFO ，實現方式就是將消息同步發送到同壹個隊列中。此處只保證發送有序，消費有序由消費者自己保證。
分布式事務： 事務，是保證壹系列操作，要麽都成功，要麽都回滾。分布式事務是在分布式系統中，保證壹系列操作，要麽都成功，要麽都失敗。
常見的分布式事務解決方案：