該如何選擇訊息佇列？
在高併發業務場景下，訊息佇列在流量削峰、解耦上有不可替代的作用。當前使用較多的訊息佇列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、Pulsar 等。
訊息佇列這麼多，到底該選擇哪款訊息佇列呢？
選擇訊息佇列的基本標準
雖然這些訊息佇列在功能和特性方面各有優劣，但我們在選擇的時候要有一個基本標準。
首先，必須是開源的產品。開源意味著，如果有一天你使用的訊息佇列遇到了一個影響你係統業務的 Bug，至少還有機會通過修改原始碼來迅速修復或規避這個 Bug，解決你的系統的問題，而不是等待開發者釋出的下一個版本來解決。
其次，這個產品必須是近年來比較流行並且有一定社群活躍度的產品。流行的好處是，只要使用場景不太冷門，遇到 Bug 的概率會非常低，因為大部分遇到的 Bug，其他人早就遇到並且修復了。在使用過程中遇到的一些問題，也比較容易在網上搜索到類似的問題，然後很快的找到解決方案。還有一個優勢就是，流行的產品與周邊生態系統會有一個比較好的整合和相容。
最後，作為一款及格的訊息佇列，必須具備的幾個特性包括：
- 訊息的可靠傳遞：確保不丟訊息；
- Cluster：支援叢集，確保不會因為某個節點宕機導致服務不可用，當然也不能丟訊息；
- 效能：具備足夠好的效能，能滿足絕大多數場景的效能要求。
接下來看一下有哪些符合上面這些條件，可供選擇的開源訊息佇列。
RabbitMQ
首先，我們來看下訊息佇列 RabbitMQ。RabbitMQ 於 2007 年釋出，是使用 Erlang 程式語言編寫的，最早是為電信行業系統之間的可靠通訊設計的，也是少數幾個支援 AMQP 協議的訊息佇列之一。
RabbitMQ：輕量級、迅捷，它的宣傳口號，也很明確地表明瞭 RabbitMQ 的特點：Messaging that just works，開箱即用的訊息佇列。也就是說，RabbitMQ 是一個相當輕量級的訊息佇列，非常容易部署和使用。
RabbitMQ 一個比較有特色的功能是支援非常靈活的路由配置，和其他訊息佇列不同的是，它在生產者（Producer）和佇列（Queue）之間增加了一個 Exchange 模組，可以理解為交換機。
Exchange 模組的作用和交換機非常相似，根據配置的路由規則將生產者發出的訊息分發到不同的佇列中。路由的規則也非常靈活，甚至可以自己來實現路由規則。如果正好需要這個功能，RabbitMQ 是個不錯的選擇。
RabbitMQ 的客戶端支援的程式語言大概是所有訊息佇列中最多的。
接下來說下 RabbitMQ 的幾個問題：
- RabbitMQ 對訊息堆積的支援並不好，當大量訊息積壓的時候，會導致 RabbitMQ 的效能急劇下降。
- RabbitMQ 的效能是這幾個訊息佇列中最差的，大概每秒鐘可以處理幾萬到十幾萬條訊息。如果應用對訊息佇列的效能要求非常高，那不要選擇 RabbitMQ。
- RabbitMQ 使用的程式語言 Erlang，擴充套件和二次開發成本高。
RocketMQ
RocketMQ 是阿里巴巴在 2012 年開源的訊息佇列產品，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進，後來捐贈給 Apache 軟體基金會，2017 正式畢業，成為 Apache 的頂級專案。RocketMQ 在阿里內部被廣泛應用在訂單，交易，充值，流計算，訊息推送，日誌流式處理，Binglog 分發等場景。經歷過多次雙十一考驗，它的效能、穩定性和可靠性都是值得信賴的。
RocketMQ 有著不錯的效能，穩定性和可靠性，具備一個現代的訊息佇列應該有的幾乎全部功能和特性，並且它還在持續的成長中。
RocketMQ 有非常活躍的中文社群，大多數問題可以找到中文的答案。RocketMQ 使用 Java 語言開發，原始碼相對比較容易讀懂，容易對 RocketMQ 進行擴充套件或者二次開發。
RocketMQ 對線上業務的響應時延做了很多的優化，大多數情況下可以做到毫秒級的響應，如果你的應用場景很在意響應時延，那應該選擇使用 RocketMQ。
RocketMQ 的效能比 RabbitMQ 要高一個數量級，每秒鐘大概能處理幾十萬條訊息。
RocketMQ 的劣勢是與周邊生態系統的整合和相容程度不夠。
Kafka
Apache Kafka 是一個分散式訊息釋出訂閱系統。它最初由 LinkedIn 公司基於獨特的設計實現為一個分散式的日誌提交系統，之後成為 Apache 專案的一部分。
在早期的版本中，為了獲得極致的效能，在設計方面做了很多的犧牲，比如不保證訊息的可靠性，可能會丟失訊息，也不支援叢集，功能上也比較簡陋，這些犧牲對於處理海量日誌這個特定的場景都是可以接受的。
但是，隨後幾年 Kafka 逐步補齊了這些短板，當下的 Kafka 已經發展為一個非常成熟的訊息佇列產品，無論在資料可靠性、穩定性和功能特性等方面都可以滿足絕大多數場景的需求。
Kafka 與周邊生態系統的相容性是最好的沒有之一，尤其在大資料和流計算領域，幾乎所有的相關開源軟體系統都會優先支援 Kafka。
Kafka 效能高效、可擴充套件良好並且可持久化。它的分割槽特性，可複製和可容錯都是不錯的特性。
Kafka 使用 Scala 和 Java 語言開發，設計上大量使用了批量和非同步的思想，使得 Kafka 能做到超高的效能。Kafka 的效能，尤其是非同步收發的效能，是三者中最好的，但與 RocketMQ 並沒有量級上的差異，大約每秒鐘可以處理幾十萬條訊息。
在有足夠的客戶端併發進行非同步批量傳送，並且開啟壓縮的情況下，Kafka 的極限處理能力可以超過每秒 2000 萬條訊息。
但是 Kafka 非同步批量的設計帶來的問題是，它的同步收發訊息的響應時延比較高，因為當客戶端傳送一條訊息的時候，Kafka 並不會立即傳送出去，而是要等一會兒攢一批再發送，在它的 Broker 中，很多地方都會使用這種先攢一波再一起處理的設計。當你的業務場景中，每秒鐘訊息數量沒有那麼多的時候，Kafka 的時延反而會比較高。所以，Kafka 不太適合線上業務場景。
訊息佇列對比
| Kafka | RocketMQ | RabbitMQ | |
|---|---|---|---|
| 單機吞吐量 | 十萬級 | 十萬級 | 萬級 |
| 開發語言 | Java & Scala | Java | Erlang |
| 訊息延遲 | 毫秒級 | 毫秒級 | 微秒級 |
| 訊息丟失 | 引數優化配置後可做到0丟失 | 引數優化配置後可做到0丟失 | 有較低的概率丟失 |
| 消費模式 | Pull | Pull+Push | Pull+Push |
| topic數量對吞吐量的影響 | topic達到幾十，幾百個時，吞吐量會大幅度下降 | topic達到幾百，幾千個時，吞吐量會有較小幅度的下降 | \ |
| 可用性 | 非常高（分散式） | 非常高（主從） | 高（主從） |
| 總結 | 吞吐量高，微秒級延時，分散式高可用，最好是支援較少topic數量，會有訊息重複現象 | 可支撐大規模topic數量，方便二次開發和擴充套件 | 不支援叢集動態擴容，擴充套件和二次開發難 |
總結
本文分別介紹了 RabbitMQ，RocketMQ 和 Kafka 幾種常見的訊息佇列，闡述了各種訊息佇列的主要特點和優劣勢。
在瞭解了上面這些開源訊息佇列各自的特點和優劣勢後，對於訊息佇列及相關技術選型，相信你會有更深入的理解和認識。以下幾條選擇的建議可以參考：
- 如果訊息佇列不是將要構建系統的重點，對訊息佇列功能和效能沒有很高的要求，只需要一個快速上手易於維護的訊息佇列，建議使用 RabbitMQ。
- 如果系統使用訊息佇列主要場景是處理線上業務，比如在交易系統中用訊息佇列傳遞訂單，需要低延遲和高穩定性，建議使用 RocketMQ。
- 如果需要處理海量的訊息，像收集日誌、監控資訊或是埋點這類資料，或是你的應用場景大量使用了大資料、流計算相關的開源產品，那 Kafka 是最適合的訊息佇列。
每一個訊息佇列都有自己的優劣勢，需要根據現有系統的情況，選擇最適合的訊息佇列，更多細節和原理性的東西，還需在實踐中見真知！
參考
http://1t.click/aA3A