訊息匯流排（ Message Queue），後文稱 MQ，是一種跨程序的通訊機制，用於上下游傳遞訊息。

MQ全稱為Message Queue, 訊息佇列（MQ）是一種應用程式對應用程式的通訊方法。應用程式透過讀寫出入佇列的訊息（針對應用程式的資料）來通訊，而無需專用連線來連結它們。訊息傳遞指的是程式之間透過在訊息中傳送資料進行通訊，而不是透過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技術。排隊指的是應用程式透過 佇列來通訊。佇列的使用除去了接收和傳送應用程式同時執行的要求。

在網際網路架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的訊息通訊服務。

使用了MQ之後，訊息傳送上游只需要依賴MQ，邏輯上和物理上都不用依賴其他服務。

既然MQ是網際網路分層架構中的解耦利器，那所有通訊都使用MQ豈不是很好？這是一個嚴重的誤區，呼叫與被呼叫的關係，是無法被MQ取代的。

MQ它是一個高效的可嵌入庫，它解決了大部分應用程式需要解決的問題，變得在網路上有良好的可伸縮性，而沒有多少成本。

它能在後臺執行緒非同步處理I/O。這些執行緒使用無鎖資料結構與應用程式執行緒進行通訊，所以併發.MQ 應用程式不再需要鎖、訊號量，或其他等待狀態。

元件可以動態地來去自如，而MQ 會自動重新連線。這意味著你可以以任何順序啟動元件。你可以建立“面向服務的架構”（SOA），其中的服務可以在任何時間加入和離開網路。

它根據需要自動對訊息排隊。為此，它會智慧地在對訊息排隊之前，將訊息儘可能地推進到接收者。

它有一個處理過滿佇列（稱為“高水位標誌”）的方法。當佇列滿時，.MQ 會自動阻止發件人，或丟棄訊息，這取決於你正在做的是哪種訊息傳遞（即所謂的“模式”）。

它可以讓你的應用程式透過任意傳輸協議來互相交流，這些協議可以是：TCP、多播、程序內、程序間。你不需要更改程式碼以使用不同的傳輸工具。

它使用依賴於訊息傳遞模式的不同策略，安全地處理速度慢/ 阻塞的讀取者。

它可以讓你採用多種模式，如請求- 應答和釋出- 訂閱來將訊息路由。這些模式是指你如何建立拓撲結構和網路結構。

它使用線上路上的簡單組幀原封不動地傳遞整個訊息。如果你寫了一個10KB 的訊息，那麼你將收到一個10KB 的訊息。

它不對訊息強加任何格式。它們是零位元組到千兆位元組的二進位制大物件。當你想表示你的資料時，可以選擇其上的其他一些產品，如谷歌的協議緩衝區、XDR 等。

它能智慧地處理網路錯誤。有時候它會重試，有時它會告訴你某個操作失敗。

它可以減少你的能源消耗。少花CPU 多辦事意味著使用電腦更少的能源，你可以讓你的舊電腦使用更長的時間。

實際上，MQ 做的比這更多。它對你如何開發網路功能的應用程式有顛覆性的影響。從表面上看，這是一個在其上做zmq_msg_recv() 和zmq_msg_send() 的套接字風格的API。但該訊息處理迴圈迅速成為中心迴圈，而你的應用程式很快就會分解成一組訊息處理任務。它是優雅和自然的。而且，它可擴充套件：每個任務對應一個節點，節點透過任意傳輸方式互相交談。在一個程序中的兩個節點（節點是一個執行緒），在一臺電腦中的兩個節點（節點是一個程序），或一個網路上的兩臺電腦（節點是一臺電腦），所有的處理方式都是相同的，不需要更改應用程式程式碼。

所以MQ在任何應用程式中以接近零的消耗開展工作。它應該是不需要任何其他依賴就可以連結的庫。無須額外的變動部件，所以沒有額外的風險。它應該能執行在任何作業系統上，並能用任何程式語言開展工作。

訊息匯流排(Message Queue)，後文稱MQ，是一種跨程序的通訊機制，用於上下游傳遞訊息。

在網際網路架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的訊息通訊服務。

使用了MQ之後，訊息傳送上游只需要依賴MQ，邏輯上和物理上都不用依賴其他服務。

什麼時候不使用訊息匯流排

既然MQ是網際網路分層架構中的解耦利器，那所有通訊都使用MQ豈不是很好?這是一個嚴重的誤區，呼叫與被呼叫的關係，是無法被MQ取代的。

MQ的不足是：

系統更復雜，多了一個MQ元件訊息傳遞路徑更長，延時會增加訊息可靠性和重複性互為矛盾，訊息不丟不重難以同時保證上游無法知道下游的執行結果，這一點是很致命的

舉個例子：使用者登入場景，登入頁面呼叫passport服務，passport服務的執行結果直接影響登入結果，此處的“登入頁面”與“passport服務”就必須使用呼叫關係，而不能使用MQ通訊。

無論如何，記住這個結論：呼叫方實時依賴執行結果的業務場景，請使用呼叫，而不是MQ。

MQ對應的優點是：

高併發

在高併發分散式環境下，由於來不及同步處理，請求往往發生堵塞，比如說，大量的insert、update之類的請求同時到達mysql，直接導致無所的行鎖和表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。透過使用訊息佇列，我們可以非同步處理請求，從而緩解系統的壓力。

松耦合

MQ提供松耦合的應用架構。松耦合一般是為了減輕經典RPC（Remote Procedure Calls）呼叫的緊耦合架構而被引入的。該松耦合以非同步形式存在，任何一個應用對MQ的呼叫不依賴於任何其它應用，沒有任何依賴或者時序要求。應用依賴於MQ的能力保證訊息傳遞。因此，我們把應用傳送訊息的形式稱之為觸發和忘記（fire-and-forget）--應用傳送訊息到MQ之後並不關心訊息如何或者什麼時候被傳遞。同樣的訊息的接收者也不關心訊息從哪裡或者如何到來。在不同的環境中這樣做的好處是允許客戶端使用不同的語言編寫甚至使用不同的線路協議。MQ作為中間人存在，允許不同環境的整合和非同步互動。

當我們考慮分散式應用設計時，耦合是很重要的。耦合是指兩個或多個應用間的相互依賴。考慮耦合的一個簡單辦法是思考其中某個應用改變所產生的影響，即其它應用所需要作出的改變。是否一個應用的變化會強制其它應用跟著改變？如果答案是肯定的，則這些應用是緊耦合的。如果一個應用的變化無需強制其它應用跟著改變，則這些應用是松耦合的。這說明了緊耦合系統比松耦合系統更難維護。也就是說，松耦合系統更能適應未知的變化。

COM,CORBA,DCE和EJB等使用RPC的技術，它們是緊耦合的。使用RPC，當一個應用呼叫另一個應用，呼叫者將被阻塞知道被呼叫者返回結果。圖1.1描述了這個過程。

呼叫方（Application one）將被阻塞直到被呼叫方（Application two）返回控制權。很多系統使用RPC並且成功了。但是對於這樣一個緊耦合系統確實有很多缺點：最顯著的缺點是，即使很小的一個改變都要較高的維護代價;正確的時機也很重要，當請求從應用1發到應用2時，兩個系統都必須正常工作，同樣的，響應從應用2傳送到應用1時，兩個系統也必須正常工作。這樣的時序要求有點麻煩，使得系統穩定性降低。現在我們把這個緊耦合系統和圖1.2的系統進行比較。

在圖1.2中，應用1傳送訊息到MOM只是一個單方行為。可能一段時間後，應用2從MOM接收訊息，這也是一個單方行為。任何一方都不需要知道另一方的存在，它們之間也沒有任何時序要求。所以在分散式系統設計時，松耦合系統比緊耦合系統有巨大的優勢。如圖所示，這就是MQ存在的地方。

考慮現在其中的一個應用必須搬到一個新的地方。這可能在新硬體引入或應用需要移動時發生。如果是一個緊耦合系統，這樣的遷移會很困難，因為系統的其它部分都必須停止工作等待遷移完成。如果是松耦合系統，系統的各個部分能夠自由遷移而不影響其它部分。考慮這樣一個場景，應用A和B各有很多個例項，其中各個例項分佈在不同的機器上。MQ安裝在另外的機器上。在這種情況下，任何一個應用例項都可以自由移動而不影響其它應用。事實上，多個MQ例項也可以透過network of brokers配置聯合使用。這就允許MQ例項自由遷移而不影響應用A或應用B。採用這種架構，系統的任何一部分在任何時間都可以停機進行維護而不影響整個系統。

MQ全稱為Message Queue,訊息佇列。（MQ）是一種應用程式對應用程式的通訊方法。應用程式透過讀寫出入佇列的訊息（針對應用程式的資料）來通訊，而無需專用連線來連結它們。訊息傳遞指的是程式之間透過在訊息中傳送資料進行通訊，而不是透過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技術。排隊指的是應用程式透過 佇列來通訊。佇列的使用除去了接收和傳送應用程式同時執行的要求。其中較為成熟的MQ產品有IBM WEBSPHERE MQ等等。在專案中，將一些無需即時返回且耗時的操作提取出來，進行了非同步處理，而這種非同步處理的方式大大的節省了伺服器的請求響應時間，從而提高了系統的吞吐量。