用訊息中介軟體猶如小馬過河，選擇合適的才最重要，這需要貼合自身的業務需求，技術服務於業務。具體在選擇上可從下面功能、效能、可靠性和可用性、運維管理、社群和生態、團隊技術棧等維度來進行篩選。

具體技術選型指標1：功能

首要的就是功能維度，這個直接決定了你能否最大程度上的實現開箱即用，進而縮短專案週期、降低成本等。如果一款訊息中介軟體的功能達不到想要的功能，那麼就需要進行二次開發，這樣會增加專案的技術難度、複雜度以及增大專案週期等。

功能維度又可以劃分個多個子維度，大致可以分為以下這些。

1. 優先順序佇列：優先順序高的訊息先被消費，若消費速度大於生產速度，MQ中沒訊息堆積，那沒多大意義；
2. 延遲佇列：延遲佇列儲存的是對應的延遲訊息，所謂“延遲訊息”是指當訊息被髮送以後，並不想讓消費者立刻拿到訊息，而是等待特定時間後，消費者才能拿到這個訊息進行消費。
3. 死信佇列：存無法被正確投遞消費的訊息，避免不能消費的回退訊息放在佇列頂部，不斷被處理和回滾陷入死迴圈。
4. 重試佇列：指消費端消費訊息失敗時，為防止訊息無故丟失而重新將訊息回滾到 Broker 中。一般分成多個重試等級，每個重試等級一般也會設定重新投遞延時，重試次數越多投遞延時就越大。為此需要設定一個上限，超過投遞次數就入死信佇列。
5. 消費模式：消費模式分為推（push）模式和拉（pull）模式。推模式是指由 Broker 主動推送訊息至消費端，實時性較好，不過需要一定的流制機制來確保服務端推送過來的訊息不會壓垮消費端。而拉模式是指消費端主動向 Broker 端請求拉取（一般是定時或者定量）訊息，實時性較推模式差，但是可以根據自身的處理能力而控制拉取的訊息量。
6. 廣播消費：訊息一般有兩種傳遞模式：點對點（P2P，Point-to-Point）模式和釋出 / 訂閱（Pub/Sub）模式。
7. 訊息回溯：指訊息在消費完成之後，還能消費到之前被消費掉的訊息。對於訊息而言，經常面臨的問題是“訊息丟失”，至於是真正由於訊息中介軟體的缺陷丟失還是由於使用方的誤用而丟失一般很難追查，如果訊息中介軟體本身具備訊息回溯功能的話，可以通過回溯消費復現“丟失的”訊息進而查出問題的源頭之所在。訊息回溯的作用遠不止與此，比如還有索引恢復、本地快取重建，有些業務補償方案也可以採用回溯的方式來實現。
8. 訊息堆積 + 持久化：流量削峰是訊息中介軟體的一個非常重要的功能，而這個功能其實得益於其訊息堆積能力。訊息堆積分記憶體式堆積和磁碟式堆積。RabbitMQ 是典型的記憶體式堆積，但這並非絕對，在某些條件觸發後會有換頁動作來將記憶體中的訊息換頁到磁碟（換頁動作會影響吞吐），或者直接使用惰性佇列來將訊息直接持久化至磁碟中。Kafka 是一種典型的磁碟式堆積，所有的訊息都儲存在磁碟中。
9. 訊息追蹤：對於分散式架構系統中的鏈路追蹤（trace）而言，大家一定不會陌生。對於訊息中介軟體而言，訊息的鏈路追蹤（以下簡稱訊息追蹤）同樣重要。對於訊息追蹤最通俗的理解就是要知道訊息從哪來，存在哪裡以及發往哪裡去。基於此功能下，我們可以對傳送或者消費完的訊息進行鏈路追蹤服務，進而可以進行問題的快速定位與排查。
10. 訊息過濾：訊息過濾是指按照既定的過濾規則為下游使用者提供指定類別的訊息。就以 kafka 而言，完全可以將不同類別的訊息傳送至不同的 topic 中，由此可以實現某種意義的訊息過濾，或者 Kafka 還可以根據分割槽對同一個 topic 中的訊息進行分類。不過更加嚴格意義上的訊息過濾應該是對既定的訊息採取一定的方式按照一定的過濾規則進行過濾。
11. 多租戶：重租賃技術，是一種軟體架構技術，主要用來實現多使用者的環境下公用相同的系統或程式元件，並且仍可以確保各使用者間資料的隔離性。RabbitMQ 就能夠支援多租戶技術，每一個租戶表示為一個 vhost，其本質上是一個獨立的小型 RabbitMQ 伺服器，又有自己獨立的佇列、交換器及繫結關係等，並且它擁有自己獨立的許可權。vhost 就像是物理機中的虛擬機器一樣，它們在各個例項間提供邏輯上的分離，為不同程式安全保密地允許資料，它既能將同一個 RabbitMQ 中的眾多客戶區分開，又可以避免佇列和交換器等命名衝突。
12. 多協議支援：為了讓生產者和消費者都能理解所承載的資訊（生產者需要知道如何構造訊息，消費者需要知道如何解析訊息），它們就需要按照一種統一的格式描述訊息，這種統一的格式稱之為訊息協議。有效的訊息一定具有某種格式，而沒有格式的訊息是沒有意義的。一般訊息層面的協議有 AMQP、MQTT、STOMP、XMPP 等（訊息領域中的 JMS 更多的是一個規範而不是一個協議），支援的協議越多其應用範圍就會越廣，通用性越強，比如 RabbitMQ 能夠支援 MQTT 協議就讓其在物聯網應用中獲得一席之地。還有的訊息中介軟體是基於其本身的私有協議運轉的，典型的如 Kafka。
13. 跨語言支援：訊息中介軟體本身具備應用解耦的特性，如果能夠進一步的支援多客戶端語言，那麼就可以將此特性的效能擴大。跨語言的支援力度也可以從側面反映出一個訊息中介軟體的流行程度。
14. 流量控制：流量控制（flow control）針對的是傳送方和接收方速度不匹配的問題，提供一種速度匹配服務抑制傳送速率使接收方應用程式的讀取速率與之相適應。通常的流控方法有 Stop-and-wait、滑動視窗以及令牌桶等。
15. 訊息順序性：指保證訊息有序。這個功能有個很常見的應用場景就是 CDC（Change Data Chapture）。
16. 安全機制：身份認證是指客戶端與服務端連線進行身份認證，許可權控制是指對客戶端的讀寫操作進行許可權控制。
17. 訊息冪等性：訊息在生產者和消費者之間進行傳輸而言一般有三種傳輸保障（delivery guarantee）：At most once，至多一次，訊息可能丟失，但絕不會重複傳輸；At least once，至少一次，訊息絕不會丟，但是可能會重複；Exactly once，精確一次，每條訊息肯定會被傳輸一次且僅一次。對於確保對於大多數訊息中介軟體而言，一般只提供 At most once 和 At least once 兩種傳輸保障，對於第三種一般很難做到，由此訊息冪等性也很難保證。不過如果要考慮全域性的冪等，還需要與從上下游方面綜合考慮，即關聯業務層面，冪等處理本身也是業務層面所需要考慮的重要議題。以下游消費者層面為例，有可能消費者消費完一條訊息之後沒有來得及確認訊息就發生異常，等到恢復之後又得重新消費原來消費過的那條訊息，那麼這種型別的訊息冪等是無法有訊息中介軟體層面來保證的。如果要保證全域性的冪等，需要引入更多的外部資源來保證，比如以訂單號作為唯一性標識，並且在下游設定一個去重表。
18. 事務性訊息：支援事務的訊息中介軟體並不在少數，Kafka 和 RabbitMQ 都支援，不過此兩者的事務是指生產者發生訊息的事務，要麼傳送成功，要麼傳送失敗。訊息中介軟體可以作為用來實現分散式事務的一種手段，但其本身並不提供全域性分散式事務的功能。

具體技術選型指標2：效能

功能維度是訊息中介軟體選型中的一個重要的參考維度，但這並不是唯一的維度。有時候效能比功能還要重要，況且效能和功能很多時候是相悖的，魚和熊掌不可兼得，Kafka 在開啟冪等、事務功能的時候會使其效能降低，RabbitMQ 在開啟 rabbitmq_tracing 外掛的時候也會極大的影響其效能。訊息中介軟體的效能一般是指其吞吐量，雖然從功能維度上來說，RabbitMQ 的優勢要大於 Kafka，但是 Kafka 的吞吐量要比 RabbitMQ 高出 1 至 2 個數量級，一般 RabbitMQ 的單機 QPS 在萬級別之內，而 Kafka 的單機 QPS 可以維持在十萬級別，甚至可以達到百萬級。

訊息中介軟體的吞吐量始終會受到硬體層面的限制。就以網絡卡頻寬為例，如果單機單網絡卡的頻寬為 1Gbps，如果要達到百萬級的吞吐，那麼訊息體大小不得超過 (1Gb/8)/100W，即約等於 134B，換句話說如果訊息體大小超過 134B，那麼就不可能達到百萬級別的吞吐。這種計算方式同樣可以適用於記憶體和磁碟。

時延作為效能維度的一個重要指標，卻往往在訊息中介軟體領域所被忽視，因為一般使用訊息中介軟體的場景對時效性的要求並不是很高，如果要求時效性完全可以採用 RPC 的方式實現。訊息中介軟體具備訊息堆積的能力，訊息堆積越大也就意味著端到端的時延也就越長，與此同時延時佇列也是某些訊息中介軟體的一大特色。那麼為什麼還要關注訊息中介軟體的時延問題呢？訊息中介軟體能夠解耦系統，對於一個時延較低的訊息中介軟體而言，它可以讓上游生產者傳送訊息之後可以迅速的返回，也可以讓消費者更加快速的獲取到訊息，在沒有堆積的情況下可以讓整體上下游的應用之間的級聯動作更加高效，雖然不建議在時效性很高的場景下使用訊息中介軟體，但是如果所使用的訊息中介軟體的時延方面比較優秀，那麼對於整體系統的效能將會是一個不小的提升。

具體技術選型指標3：可靠性 + 可用性

訊息丟失是使用訊息中介軟體時所不得不面對的一個同點，其背後訊息可靠性也是衡量訊息中介軟體好壞的一個關鍵因素。尤其是在金融支付領域，訊息可靠性尤為重要。然而說到可靠性必然要說到可用性，注意這兩者之間的區別，訊息中介軟體的可靠性是指對訊息不丟失的保障程度；而訊息中介軟體的可用性是指無故障執行的時間百分比，通常用幾個 9 來衡量。

從狹義的角度來說，分散式系統架構是一致性協議理論的應用實現，對於訊息可靠性和可用性而言也可以追溯到訊息中介軟體背後的一致性協議。對於 Kafka 而言，其採用的是類似 PacificA 的一致性協議，通過 ISR（In-Sync-Replica）來保證多副本之間的同步，並且支援強一致性語義（通過 acks 實現）。對應的 RabbitMQ 是通過映象環形佇列實現多副本及強一致性語義的。多副本可以保證在 master 節點宕機異常之後可以提升 slave 作為新的 master 而繼續提供服務來保障可用性。Kafka 設計之初是為日誌處理而生，給人們留下了資料可靠性要求不高的不良印象，但是隨著版本的升級優化，其可靠性得到極大的增強，詳細可以參考 KIP101。就目前而言，在金融支付領域使用 RabbitMQ 居多，而在日誌處理、大資料等方面 Kafka 使用居多，隨著 RabbitMQ 效能的不斷提升和 Kafka 可靠性的進一步增強，相信彼此都能在以前不擅長的領域分得一杯羹。

同步刷盤是增強一個元件可靠性的有效方式，訊息中介軟體也不例外，Kafka 和 RabbitMQ 都可以支援同步刷盤，但是筆者對同步刷盤有一定的疑問：絕大多數情景下，一個元件的可靠性不應該由同步刷盤這種極其損耗效能的操作來保障，而是採用多副本的機制來保證。

這裡還要提及的一個方面是擴充套件能力，這裡我狹隘地將此歸納到可用性這一維度，訊息中介軟體的擴充套件能力能夠增強其用可用能力及範圍，比如前面提到的 RabbitMQ 支援多種訊息協議，這個就是基於其外掛化的擴充套件實現。還有從叢集部署上來講，歸功於 Kafka 的水平擴充套件能力，其基本上可以達到線性容量提升的水平，在 LinkedIn 實踐介紹中就提及了有部署超過千臺裝置的 Kafka 叢集。

具體技術選型指標4：運維管理

在訊息中介軟體的使用過程中難免會出現各式各樣的異常情況，有客戶端的，也有服務端的，那麼怎樣及時有效的進行監測及修復。業務線流量有峰值又低谷，尤其是電商領域，那麼怎樣前進行有效的容量評估，尤其是大促期間？腳踢電源、網線被挖等事件層出不窮，如何有效的做好異地多活？這些都離不開訊息中介軟體的衍生產品——運維管理。

運維管理也可以進行進一步的細分，比如：申請、稽核、監控、告警、管理、容災、部署等。

申請、稽核很好理解，在源頭對資源進行管控，既可以進行有效校正應用方的使用規範，配和監控也可以做好流量統計與流量評估工作，一般申請、稽核與公司內部系統交融性較大，不適合使用開源類的產品。

監控、告警也比較好理解，對訊息中介軟體的使用進行全方位的監控，即可以為系統提供基準資料，也可以在檢測到異常的情況配合告警，以便運維、開發人員的迅速介入。除了一般的監控項（比如硬體、GC 等）之外，對於訊息中介軟體還需要關注端到端時延、訊息審計、訊息堆積等方面。對於 RabbitMQ 而言，最正統的監控管理工具莫過於 rabbitmq_management 外掛了，但是社群內還有 AppDynamics, Collectd, DataDog, Ganglia, Munin, Nagios, New Relic, Prometheus, Zenoss 等多種優秀的產品。Kafka 在此方面也毫不遜色，比如：Kafka Manager, Kafka Monitor, Kafka Offset Monitor, Burrow, Chaperone, Confluent Control Center 等產品，尤其是 Cruise 還可以提供自動化運維的功能。

不管是擴容、降級、版本升級、叢集節點部署、還是故障處理都離不開管理工具的應用，一個配套完備的管理工具集可以在遇到變更時做到事半功倍。故障可大可小，一般是一些應用異常，也可以是機器掉電、網路異常、磁碟損壞等單機故障，這些故障單機房內的多副本足以應付。如果是機房故障就要涉及異地容災了，關鍵點在於如何有效的進行資料複製，對於 Kafka 而言，可以參考 MirrorMarker、uReplicator 等產品，而 RabbitMQ 可以參考 Federation 和 Shovel。

具體技術選型指標5：社群力度及生態發展

對於目前流行的程式語言而言，如 Java、Python，如果你在使用過程中遇到了一些異常，基本上可以通過搜尋引擎的幫助來得到解決，因為一個產品用的人越多，踩過的坑也就越多，對應的解決方案也就越多。對於訊息中介軟體也同樣適用，如果你選擇了一種“生僻”的訊息中介軟體，可能在某些方面運用的得心應手，但是版本更新緩慢、遇到棘手問題也難以得到社群的支援而越陷越深；相反如果你選擇了一種“流行”的訊息中介軟體，其更新力度大，不僅可以迅速的彌補之前的不足，而且也能順應技術的快速發展來變更一些新的功能，這樣可以讓你以“站在巨人的肩膀上”。在運維管理維度我們提及了 Kafka 和 RabbitMQ 都有一系列開源的監控管理產品，這些正是得益於其社群及生態的迅猛發展。

訊息中介軟體選型還有一個考量標準就是儘量貼合團隊自身的技術棧體系，雖然說沒有蹩腳的訊息中介軟體只有蹩腳的程式設計師，但是讓一個 C 棧的團隊去深挖 PhxQueue 總比去深挖 Scala 編寫的 Kafka 要容易的多。

訊息中介軟體選型切忌一味的追求效能或者功能，效能可以優化，功能可以二次開發。如果要在功能和效能方面做一個抉擇的話，那麼首選效能，因為總體上來說效能優化的空間沒有功能擴充套件的空間大。然而對於長期發展而言，生態又比效能以及功能都要重要。

訊息中介軟體大道至簡：一發一存一消費，沒有最好的訊息中介軟體，只有最合適的訊息中介軟體。

 <http://www.52im.net/thread-1647-1-1.html>