作為一個程式設計師，相信你一定聽過“沒有銀彈”這個說法，這裡面的銀彈是指能輕鬆殺死狼人、用白銀做的子彈，什麼意思呢？我對這句話的理解是說，在軟體工程中，不存在像“銀彈”這樣可以解決一切問題的設計、架構或軟體，每一個軟體系統，它都是獨一無二的，你不可能用一套方法去解決所有的問題。在訊息佇列的技術選型這個問題上，也是同樣的道理。並不存在說，哪個訊息佇列就是“最好的”。常用的這幾個訊息佇列，每一個產品都有自己的優勢和劣勢，你需要根據現有系統的情況，選擇最適合你的那款產品。
選擇訊息佇列產品的基本標準
雖然這些訊息佇列產品在功能和特性方面各有優劣，但我們在選擇的時候要有一個最低標準，保證入選的產品至少是及格的。接下來我們先說一下這及格的標準是什麼樣的。
首先，必須是開源的產品，這個非常重要。開源意味著，如果有一天你使用的訊息佇列遇到了一個影響你係統業務的 Bug，你至少還有機會通過修改原始碼來迅速修復或規避這個 Bug，解決你的系統火燒眉毛的問題，而不是束手無策地等待開發者不一定什麼時候釋出的下一個版本來解決。其次，這個產品必須是近年來比較流行並且有一定社群活躍度的產品。流行的好處是，只要你的使用場景不太冷門，你遇到 Bug 的概率會非常低，因為大部分你可能遇到的 Bug，其他人早就遇到並且修復了。你在使用過程中遇到的一些問題，也比較容易在網上搜索到類似的問題，然後很快的找到解決方案。
還有一個優勢就是，流行的產品與周邊生態系統會有一個比較好的整合和相容，比如，Kafka 和 Flink 就有比較好的相容性，Flink 內建了 Kafka 的 Data Source，使用 Kafka 就很容易作為 Flink 的資料來源開發流計算應用，如果你用一個比較小眾的訊息佇列產品，在進行流計算的時候，你就不得不自己開發一個 Flink 的 Data Source。
最後，作為一款及格的訊息佇列產品，必須具備的幾個特性包括：

訊息的可靠傳遞：確保不丟訊息；
Cluster：支援叢集，確保不會因為某個節點宕機導致服務不可用，當然也不能丟訊息；
效能：具備足夠好的效能，能滿足絕大多數場景的效能要求。

可供選擇的訊息佇列產品
1. RabbitMQ
首先，我們說一下老牌兒訊息佇列 RabbitMQ，俗稱兔子 MQ。RabbitMQ 是使用一種比較小眾的程式語言：Erlang 語言編寫的，它最早是為電信行業系統之間的可靠通訊設計的，也是少數幾個支援 AMQP 協議的訊息佇列之一。RabbitMQ 就像它的名字中的兔子一樣：輕量級、迅捷，它的 Slogan，也就是宣傳口號，也很明確地表明瞭 RabbitMQ 的特點：Messaging that just works，“開箱即用的訊息佇列”。也就是說，RabbitMQ 是一個相當輕量級的訊息佇列，非常容易部署和使用。另外 RabbitMQ 還號稱是世界上使用最廣泛的開源訊息佇列，是不是真的使用率世界第一，我們沒有辦法統計，但至少是“最流行的訊息中間之一”，這是沒有問題的。RabbitMQ 一個比較有特色的功能是支援非常靈活的路由配置，和其他訊息佇列不同的是，它在生產者（Producer）和佇列（Queue）之間增加了一個 Exchange 模組，你可以理解為交換機。這個 Exchange 模組的作用和交換機也非常相似，根據配置的路由規則將生產者發出的訊息分發到不同的佇列中。路由的規則也非常靈活，甚至你可以自己來實現路由規則。基於這個 Exchange，可以產生很多的玩兒法，如果你正好需要這個功能，RabbitMQ 是個不錯的選擇。RabbitMQ 的客戶端支援的程式語言大概是所有訊息佇列中最多的，如果你的系統是用某種冷門語言開發的，那你多半可以找到對應的 RabbitMQ 客戶端。接下來說下 RabbitMQ 的幾個問題。第一個問題是，RabbitMQ 對訊息堆積的支援並不好，在它的設計理念裡面，訊息佇列是一個管道，大量的訊息積壓是一種不正常的情況，應當儘量去避免。當大量訊息積壓的時候，會導致 RabbitMQ 的效能急劇下降。第二個問題是，RabbitMQ 的效能是我們介紹的這幾個訊息佇列中最差的，根據官方給出的測試資料綜合我們日常使用的經驗，依據硬體配置的不同，它大概每秒鐘可以處理幾萬到十幾萬條訊息。其實，這個效能也足夠支撐絕大多數的應用場景了，不過，如果你的應用對訊息佇列的效能要求非常高，那不要選擇 RabbitMQ。最後一個問題是 RabbitMQ 使用的程式語言 Erlang，這個程式語言不僅是非常小眾的語言，更麻煩的是，這個語言的學習曲線非常陡峭。
大多數流行的程式語言，比如 Java、C/C++、Python 和 JavaScript，雖然語法、特性有很多的不同，但它們基本的體系結構都是一樣的，你只精通一種語言，也很容易學習其他的語言，短時間內即使做不到精通，但至少能達到“會用”的水平。就像一個以英語為母語的人，學習法語、德語都很容易，但是你要是讓他去學漢語，那基本上和學習其他這些語言不是一個難度級別的。很不幸的是，Erlang 就是程式語言中的“漢語”。所以如果你想基於 RabbitMQ 做一些擴充套件和二次開發什麼的，建議你慎重考慮一下可持續維護的問題。
2. RocketMQ

RocketMQ 是阿里巴巴在 2012 年開源的訊息佇列產品，後來捐贈給 Apache 軟體基金會，2017 正式畢業，成為 Apache 的頂級專案。阿里內部也是使用 RocketMQ 作為支撐其業務的訊息佇列，經歷過多次“雙十一”考驗，它的效能、穩定性和可靠性都是值得信賴的。作為優秀的國產訊息佇列，近年來越來越多的被國內眾多大廠使用。我在總結 RocketMQ 的特點時，發現很難找出 RocketMQ 有什麼特別讓我印象深刻的特點，也很難找到它有什麼缺點。RocketMQ 就像一個品學兼優的好學生，有著不錯的效能，穩定性和可靠性，具備一個現代的訊息佇列應該有的幾乎全部功能和特性，並且它還在持續的成長中。
RocketMQ 有非常活躍的中文社群，大多數問題你都可以找到中文的答案，也許會成為你選擇它的一個原因。另外，RocketMQ 使用 Java 語言開發，它的貢獻者大多數都是中國人，原始碼相對也比較容易讀懂，你很容易對 RocketMQ 進行擴充套件或者二次開發。RocketMQ 對線上業務的響應時延做了很多的優化，大多數情況下可以做到毫秒級的響應，如果你的應用場景很在意響應時延，那應該選擇使用 RocketMQ。RocketMQ 的效能比 RabbitMQ 要高一個數量級，每秒鐘大概能處理幾十萬條訊息。RocketMQ 的一個劣勢是，作為國產的訊息佇列，相比國外的比較流行的同類產品，在國際上還沒有那麼流行，與周邊生態系統的整合和相容程度要略遜一籌。
3. Kafka
最後我們聊一聊 Kafka。Kafka 最早是由 LinkedIn 開發，目前也是 Apache 的頂級專案。Kafka 最初的設計目的是用於處理海量的日誌。在早期的版本中，為了獲得極致的效能，在設計方面做了很多的犧牲，比如不保證訊息的可靠性，可能會丟失訊息，也不支援叢集，功能上也比較簡陋，這些犧牲對於處理海量日誌這個特定的場景都是可以接受的。這個時期的 Kafka 甚至不能稱之為一個合格的訊息佇列。但是，請注意，重點一般都在後面。隨後的幾年 Kafka 逐步補齊了這些短板，你在網上搜到的很多訊息佇列的對比文章還在說 Kafka 不可靠，其實這種說法早已經過時了。當下的 Kafka 已經發展為一個非常成熟的訊息佇列產品，無論在資料可靠性、穩定性和功能特性等方面都可以滿足絕大多數場景的需求。
Kafka 與周邊生態系統的相容性是最好的沒有之一，尤其在大資料和流計算領域，幾乎所有的相關開源軟體系統都會優先支援 Kafka。
Kafka 使用 Scala 和 Java 語言開發，設計上大量使用了批量和非同步的思想，這種設計使得 Kafka 能做到超高的效能。Kafka 的效能，尤其是非同步收發的效能，是三者中最好的，但與 RocketMQ 並沒有量級上的差異，大約每秒鐘可以處理幾十萬條訊息。
我曾經使用配置比較好的伺服器對 Kafka 進行過壓測，在有足夠的客戶端併發進行非同步批量傳送，並且開啟壓縮的情況下，Kafka 的極限處理能力可以超過每秒 2000 萬條訊息。但是 Kafka 這種非同步批量的設計帶來的問題是，它的同步收發訊息的響應時延比較高，因為當客戶端傳送一條訊息的時候，Kafka 並不會立即傳送出去，而是要等一會兒攢一批再發送，在它的 Broker 中，很多地方都會使用這種“先攢一波再一起處理”的設計。當你的業務場景中，每秒鐘訊息數量沒有那麼多的時候，Kafka 的時延反而會比較高。所以，Kafka 不太適合線上業務場景。
第二梯隊的訊息佇列
除了上面給你介紹的三大訊息佇列之外，還有幾個第二梯隊的產品，我個人的觀點是，這些產品之所以沒那麼流行，或多或少都有著比較明顯的短板，不推薦使用。在這兒呢，我簡單介紹一下，純當豐富你的知識廣度。先說 ActiveMQ，ActiveMQ 是最老牌的開源訊息佇列，是十年前唯一可供選擇的開源訊息佇列，目前已進入老年期，社群不活躍。無論是功能還是效能方面，ActiveMQ 都與現代的訊息佇列存在明顯的差距，它存在的意義僅限於相容那些還在用的爺爺輩兒的系統。接下來說說 ZeroMQ，嚴格來說 ZeroMQ 並不能稱之為一個訊息佇列，而是一個基於訊息佇列的多執行緒網路庫，如果你的需求是將訊息佇列的功能整合到你的系統程序中，可以考慮使用 ZeroMQ。最後說一下 Pulsar，很多人可能都沒聽說過這個產品，Pulsar 是一個新興的開源訊息佇列產品，最早是由 Yahoo 開發，目前處於成長期，流行度和成熟度相對沒有那麼高。與其他訊息佇列最大的不同是，Pulsar 採用儲存和計算分離的設計，我個人非常喜歡這種設計，它有可能會引領未來訊息佇列的一個發展方向，建議你持續關注這個專案。

總結

如果說，訊息佇列並不是你將要構建系統的主角之一，你對訊息佇列功能和效能都沒有很高的要求，只需要一個開箱即用易於維護的產品，我建議你使用 RabbitMQ。

如果你的系統使用訊息佇列主要場景是處理線上業務，比如在交易系統中用訊息佇列傳遞訂單，那 RocketMQ 的低延遲和金融級的穩定性是你需要的。

如果你需要處理海量的訊息，像收集日誌、監控資訊或是前端的埋點這類資料，或是你的應用場景大量使用了大資料、流計算相關的開源產品，那 Kafka 是最適合你的訊息佇列。

如果我說的這些場景和你的場景都不符合，你看了我之前介紹的這些訊息佇列的特點後，還是不知道如何選擇，那就選你最熟悉的吧，畢竟這些產品都能滿足大多數應用場景，使用熟悉的產品還可以快速上手不是？