這篇文章主要描述如何進行消息隊列產品選型，包括產品選型需要考慮的因素、三種比較流行的消息隊列產品的優缺點以及如何根據我們的使用場景選擇合適的消息隊列產品。 ...
圖靈獎得主弗雷德里克·布魯克斯（Frederick P.Brooks Jr.）在他的經典著作《人月神話》中提出了“沒有銀彈”的觀點，在軟體工程中，每一個軟體系統，都具有獨特性，不存在像“銀彈”一樣的解決方案，可以解決一切問題。
對於消息隊列來說也是一樣的，我們常用的消息隊列技術選型，都有各自的優勢和劣勢，我們需要根據自己的應用場景，選擇合適的消息隊列解決方案。
消息隊列選擇標準
拋開不同的消息隊列在功能和特性上的區別，當我們做消息隊列技術選型時，有一些通用的標準需要考慮。
- 消息隊列產品是開源的，這樣如果有一天使用消息隊列時遇到一個影響業務功能的Bug，我們還可以通過修改源代碼迅速修複。
- 消息隊列產品是比較流行並且有一定活躍度的社區，這樣只要你的應用場景不是特別冷門，那麼你在使用過程中遇到的問題，基本是別人也會遇到並且已經修複的。
- 一款合格的消息隊列產品還需要具備以下特性：
- 消息的可靠傳遞，確保不丟消息。
- 支持集群，確保不會因為某個節點宕機導致服務不可用。
- 具有良好的性能，滿足絕大多數場景需求。
常見的消息隊列產品
我們主要討論三個常見的消息隊列產品：
- RabbitMQ
- RocketMQ
- Kafka
RabbitMQ
RabbitMQ是一個輕量級的消息隊列，它使用Erlang語言編寫，最早是為電信行業系統之間的可靠通信設計的，官網地址：https://www.rabbitmq.com/。
RabbitMQ一個有特色的功能是支持非常靈活的路由配置，它在生產者和隊列之間增加了Exchange模塊，可以根據配置的路由規則將生產者發出的消息發到不同的隊列中，路由規則可以非常靈活，甚至我們可以自己來實現路由規則。
RabbitMQ的客戶端支持很多不同的編程語言，如果我們的應用使用的編程語言比較冷門，那麼很有可能你能找到對應語言的RabbitMQ客戶端。
RabbitMQ存在3個問題：
- RabbitMQ對消息堆積的支持不好，它的設計理念是消息隊列是一個管道，大量的消息積壓是一種不正常的情況，應當去避免。
- RabbitMQ的性能是我們考察的三個消息隊列產品中最差的，它每秒可以處理幾萬到十幾萬條消息，如果我們的應用場景對消息隊列的性能要求非常高，那麼RabbitMQ就不是合適的選擇。
- RabbitMQ使用的變成語言是Erlang，這個編程語言不僅小眾，而且學習曲線很陡峭。
RocketMQ
RocketMQ是阿裡巴巴在2012年開源的消息隊列產品，後來捐贈給Apache軟體基金會，2017年正式畢業，稱為Apache的頂級項目。RocketMQ的官網地址：https://rocketmq.apache.org/。
RocketMQ使用Java語言編寫，它有非常活躍的中文社區，你遇到的大多數問題都可以找到中文的答案。
RocketMQ對線上業務的響應時延做了大量優化，大多數情況下可以做到毫秒級響應，如果我們的應用場景中時延響應非常重要，那麼可以選擇RocketMQ。
RocketMQ的性能要比RabbitMQ高一個數量級，每秒鐘可以處理幾十萬條消息。
RocketMQ的一個劣勢是它在國外沒有那麼流行，與周邊生態系統集成和相容稍微差一些。
Kafka
Kafka最早由LinkedIn開發，目前也是Apache的頂級項目，官網地址：https://kafka.apache.org/
Kafka目前已經是一個非常成熟的消息隊列產品，無論是在數據可靠性、穩定性還是功能特性等方面都可以滿足絕大多數場景的需求。
Kafka使用Scala和Java語言開發，設計上大量使用了批量和非同步的思想，這樣可以讓Kafka做到高性能，Kafka的性能，特別是非同步收發的性能，是這三款消息隊列產品中最好的。它在性能上和RocketMQ沒有數量級上的差別，每秒鐘可以處理幾十萬條消息。
Kafka與周邊生態系統的相容性是最好的沒有之一，尤其是在大數據和流計算領域，幾乎所有的相關開源軟體都會優先選擇支持Kafka。
Kafka存在的問題是同步收發消息的響應時延比較高，當客戶端發送一條消息時，Kafka並不會立即發送出去，而是要等一會兒攢在一批再統一發送，在它的Broker中很多地方還存在“攢一波再處理”的設計，當我們的業務場景中每秒鐘的消息數量沒有那麼多時，Kafka的時延反而會比較高，因此，Kafka不太適合線上業務場景。
其他消息隊列
除了上述三款比較流行的消息隊列產品，我們還可以看一下處於“第二梯隊”的消息隊列產品，包括：
- ActiveMQ
- ZeroMQ
ActiveMQ
ActiveMQ是最老牌的消息隊列，目前已經進入老年期，社區不活躍，它存在的主要意義僅限於相容哪些還在用的軟體系統。
ActiveMQ的官網地址：https://activemq.apache.org/。
ZeroMQ
ZeroMQ嚴格意義上講不是一個消息隊列，而是基於消息隊列的多線程網路庫，如果我們的應用場景需要將消息隊列的功能集成到系統進程中，可以考慮使用ZeroMQ。
ZeroMQ的官網地址：https://zeromq.org/。
Pulsar的官網地址：https://pulsar.apache.org/。
如何選擇合適的消息隊列產品？
結合上面描述的各個消息隊列產品，我們可以得出下麵的建議。
- 如果消息隊列不是我們將要構建的系統的關鍵組件，而且我們對性能也沒有很高的要求，只是需要一個開箱即用易於維護的產品，那麼可以選擇RabbitMQ。
- 如果我們的應用場景是處理線上業務，那麼RocketMQ的低延遲和金融級的穩定性是我們需要的。
- 如果我們需要處理海量消息，或者我們場景中使用了大數據、流計算等開源產品，那麼Kafka是最合適的消息隊列。
