案例：Bob向Smith轉賬，那我們到底是先發送訊息，還是先執行扣款操作？ 
好像都可能會出問題。如果先發訊息，扣款操作失敗，那麼Smith的賬戶裡面會多出一筆錢。反過來，如果先執行扣款操作，後傳送訊息，那有可能扣款成功了但是訊息沒發出去，Smith收不到錢。除了上面介紹的通過異常捕獲和回滾的方式外，還有沒有其他的思路呢？

下面以阿里巴巴的RocketMQ中介軟體為例，分析下其設計和實現思路。

RocketMQ第一階段傳送Prepared訊息時，會拿到訊息的地址，第二階段執行本地事物，第三階段通過第一階段拿到的地址去訪問訊息，並修改狀態。但是，如果確認訊息傳送失敗了怎麼辦？

RocketMQ會定期掃描訊息叢集中的事物訊息，這時候發現了Prepared訊息，它會向訊息傳送者確認，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續傳送確認訊息呢？RocketMQ會根據傳送端設定的策略來決定是回滾還是繼續傳送確認訊息。這樣就保證了訊息傳送與本地事務同時成功或同時失敗。如下圖： 

總結：據瞭解，各大知名的電商平臺和網際網路公司，幾乎都是採用類似的設計思路來實現“最終一致性”的。這種方式適合的業務場景廣泛，而且比較可靠。不過這種方式技術實現的難度比較大。目前主流的開源MQ（ActiveMQ、RabbitMQ、Kafka）均未實現對事務訊息的支援，所以需二次開發或者新造輪子。比較遺憾的是，RocketMQ事務訊息部分的程式碼也並未開源，需要自己去實現。