訊息中介軟體的可靠性是指對訊息不丟失的保障程度；而訊息中介軟體的可用性是指無故障執行的時間百分比，通常用幾個 9 來衡量。不存在絕對的可靠性只能儘量趨向完美。並且通常可靠性也意味著影響效能和付出更大的成本，因此實際應用時還要根據業務需求，對真正關鍵的資訊來做可靠性保證，並要從生產者、訊息佇列、消費者三個維度來努力。
如果在傳送訊息時採用了事務機制或者publisher confirm機制的話，服務端的返回是在訊息落盤之後執行的，這樣可以進一步的提高了訊息的可靠性。但是即便如此也無法避免單機故障且無法修復（比如磁碟損毀）而引起的訊息丟失，這裡就需要引入映象佇列。映象佇列相當於配置了副本，絕大多數分散式的東西都有多副本的概念來確保HA。在映象佇列中，如果主節點（master）在此特殊時間內掛掉，可以自動切換到從節點（slave），這樣有效的保證了高可用性，除非整個叢集都掛掉。雖然這樣也不能完全的保證RabbitMQ訊息不丟失（比如機房被炸。。。），但是配置了映象佇列要比沒有配置映象佇列的可靠性要高很多，在實際生產環境中的關鍵業務佇列一般都會設定映象佇列。
一個軟體（程式庫）可支援多種協議（例如ActiveMQ實現了多種訊息協議），某一種協議（尤其是開放協議）也可被多種軟體（程式庫）實現（例如能夠支援webservice協議的程式庫就有Codehaus XFire、Apache CXF、Jboss RESTEasy等）
分散式系統中常用通訊模型主要是“請求-應答”模型和“釋出-訂閱”模型。前者常見如RPC通訊，常用HTTP REST或Thrift等協議；後者多指訊息佇列MQ通訊。
RPC大多屬於請求-應答模式，也包括越來越多響應式正規化，對於需要點對點互動、強事務保證和延遲敏感的服務/應用之間的通訊，RPC是優於訊息佇列的。那麼訊息佇列（下文也簡稱MQ，即Message Queue）可以看做是一種非同步RPC，把一次RPC變為兩次或多次，進行內容轉存，再在合適的時機投遞出去。訊息佇列中介軟體往往是一個分散式系統，內部元件間的通訊仍然會用到RPC。
通過JMS規範，開發人員可以忽略各種訊息協議的細節，只要訊息在同一佇列中，就能夠保證各種訊息協議間實現互相轉換。
如果您不特別指定ActiveMQ的網路監聽埠，那麼這些埠都將使用BIO網路IO模型。所以為了首先提高單節點的網路吞吐效能，我們需要明確指定Active使用NIO網路模型。
比起訊息生產者來說訊息消費者的效能更能影響ActiveMQ系統的整體效能，因為要成功完成一條訊息的處理，它的工作要遠遠多於訊息生產者。預設情況下ActiveMQ服務端採用非同步方式向客戶端推送訊息。也就是說ActiveMQ服務端在向某個消費者會話推送訊息後，不會等待消費者的響應資訊，直到消費者處理完訊息後，主動向服務端返回處理結果。
ActiveMQ中設定的各種預設預取數量一般情況下不需要進行改變。但是非必要情況下，請不要設定prefetchSize=1，因為這樣就是一條一條的取資料；也不要設定為prefetchSize=0，因為這將導致關閉伺服器端的推送機制，改為客戶端主動請求。