系統學習消息隊列分享（三） 該如何選擇消息隊列？

聊一下幾個比較常見的開源的消息隊列中間件。若是你正在作消息隊列技術選型，不知道該選擇哪款消息隊列，你必定要先聽一下這節課的內容。

做爲一個程序員，相信你必定聽過「沒有銀彈」這個說法，這裏面的銀彈是指能輕鬆殺死狼人、用白銀作的子彈，什麼意思呢？我對這句話的理解是說，在軟件工程中，不存在像「銀彈」這樣能夠解決一切問題的設計、架構或軟件，每個軟件系統，它都是獨一無二的，你不可能用一套方法去解決全部的問題。

在消息隊列的技術選型這個問題上，也是一樣的道理。並不存在說，哪一個消息隊列就是「最好的」。經常使用的這幾個消息隊列，每個產品都有本身的優點和劣勢，你須要根據現有系統的狀況，選擇最適合你的那款產品。

選擇消息隊列產品的基本標準

雖然這些消息隊列產品在功能和特性方面各有優劣，但咱們在選擇的時候要有一個最低標準，保證入選的產品至少是及格的。

接下來咱們先說一下這及格的標準是什麼樣的。

首先，必須是開源的產品，這個很是重要。開源意味着，若是有一天你使用的消息隊列遇到了一個影響你係統業務的 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 是最適合你的消息隊列。

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