圖靈獎得主弗雷德里克·布魯克斯（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是最合適的訊息佇列，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/545893.html
標籤：架構設計
下一篇：Iterator模式