消費者走向: Customer--->Name Server--->Broker

SendResult sendResult = producer.send(msg);

部署Broker
部署方式包含單Master、多Master、多Master多Slave(叢集採用非同步複製方式)、多Master多Slave(叢集採用同步雙寫方式)等四大類組成
單Master: 優點：除了配置簡單沒什麼優點
          缺點：不可靠，該機器重啟或宕機，將導致整個服務不可用
多Master:優點：配置簡單，效能最高
缺點：可能會有少量訊息丟失（配置相關），單臺機器重啟或宕機期間，該機器下未被消費的訊息在機器恢復前不可訂閱，影響訊息實時性
多Master多Slave(叢集採用非同步複製方式):   
優點：效能同多Master幾乎一樣，實時性高，主備間切換對應用透明，不需人工干預
        缺點：Master宕機或磁碟損壞時會有少量訊息丟失
多Master多Slave(叢集採用同步雙寫方式):
       優點：服務可用性與資料可用性非常高
       缺點：效能比非同步叢集略低，當前版本主宕備不能自動切換為主

訊息佇列分散式事務

一般用法比較廣泛的訊息佇列有rabbitMQ、rocketMQ、kafka等訊息中介軟體，但是rabbitMQ和kafka這兩個訊息中介軟體沒有事務，接下來我們以rocketMQ舉例子,

我們以一個轉帳的場景為例來說明這個問題：Bob向Smith轉賬100塊。

在開發中我們將大事務拆分成=小事務+非同步

事務流程：

第一步：首先生產者傳送Prepared訊息給MQ，狀態為不可消費狀態(就是消費者無法訊息)   ---該訊息包含Smith姓名以及轉賬金額和狀態等等

第二步：執行本地事務   ---該事務就是從Bob賬戶扣款100塊

第三部：如果本地事務執行失敗就回滾，並將Prepared訊息刪除，如果本地事務執行成功，確認訊息傳送(就是修改Prepared訊息狀態為可消費狀態)

第四步：消費端開始消費佇列。如果成功，給MQ返回回執。表示成功，生產者可以訂閱該訊息或者監聽該訊息，表示整個訊息佇列是成功的  --比如：支付包賬戶餘額轉到銀行卡。到賬狀態和時間都是靠生產者監聽和訂閱MQ實現轉賬成功的邏輯。

如果訊息端出現消費失敗（這裡有好多原因：程式報錯，賬戶被凍結了等等）,那麼MQ可以重發訊息。可以設定6次，超過次數可人工處理。