MQ解決什么問題?
要了解MQ的必要性，需要先了解一下微服務的產生與出現的問題。只有了解了問題產生的原因才能明白MQ的作用。
舉個栗子：支付業務
單服務
傳統的服務以單服務為主，所有的操作由一個服務器中的一個服務提供，如下圖，支付、修改訂單狀態、創建物流訂單。
image.png
三個步驟可以放在一個jdbc事務中。一旦哪個步驟出錯，其它兩個步驟都會放棄。
以防止出現：支付完了，沒有訂單。訂單狀態已經更改，沒有產生物流訂單。要么都成功，要么都失敗。以保證業務的正確性。
微服務
在微服務的環境下，會將三個步驟拆分成三個服務，例如：支付服務，訂單服務，物流服務。三者顧名思義只做好自己的一件事情。
image.png
情況會變復雜，同樣以支付業務為例，三個步驟需要有服務間的調用，如下圖，有兩次調用產生，服務間調用一般有兩種方式：restful 的http與RPC。這里不討論兩者的區別。
微服務化的好處：化整為零，單一服務制作單一的事情，可以防止單服務無線膨脹。無論從開發，測試，運維方面單個服務都是占優勢的。
微服務帶來的問題：
- 分布式事務
服務間調用難以保持一致性。例如上圖中的兩次調用。因為三個步驟操作的不是同一個數據庫，導致無法使用jdbc事務管理以達到一致性。而且兩次服務調用，因為涉及到復雜的網絡環境，很容易出現，服務調用失敗。所以，微服務化之后出現的一個很嚴重的問題就是，分布式事務問題如何解決。
分布式事務？
分布式事務有幾種解決方案，這里僅討論MQ如何解決分布式事務。
- 兩階段提交
- 補償事務
- 本地消息表
- MQ 事務消息
MQ作為解決分布式事務的一種，是如何解決分布式事務問題的，如下圖，支付服務完成支付步驟后，往MQ發送一條已支付消息，訂單服務收到消息后更改訂單狀態。
MQ
有人就想說，這沒什么區別么，甚至加了一層MQ，導致需要兩次調用，更復雜風險更大？
MQ解決分布式事務是這樣做的，A服務保證消息發送成功，MQ保證消息不會丟失，B服務保證消息消費成功。會出現以下情況：
- A服務生產消息失敗，回滾支付操作，業務回到最初狀態，保證了一致性。
- A服務生產消息成功，完成支付操作，MQ宕機，MQ重啟后，消息還存在，訂單服務消費消息，完成修改訂單操作。保證了一致性。
- A服務生產消息成功，MQ良好，訂單服務消費消息失敗。但是消息還存在，等訂單服務重啟后繼續消費消息，保證了一致性。
以上就是分布式事務中的最終一致性：即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。
MQ作為完成最終一致性的一種工具。RocketMQ也有自己的事務消息更簡單的解決以上問題。
