一、選擇消息隊列產品的基本標準
在消息隊列的技術選型上，並不存在說哪個消息隊列就是“最好的”。常用的幾個消息隊列，每個產品都有自己的優勢和劣勢，需要根據現有系統的情況，選擇最適合的那款產品。
技術產品的及格標準：
- 必須是開源產品：如果遇到Bug至少有機會通過修改源代碼迅速修復或規避，解決燃眉之急。
- 必須是近年來比較流行並且有一定社區活躍度的產品：流行的好處是，只要使用的場景不太冷門，遇到的Bug都可以找到解決辦法。
- 流行的產品與周邊生態系統會有一個比較好的集成和兼容：比如kafka和Flink就有比較好的兼容性，Flink內置了kafka的Data Sourse，使得你不用自己開發一個Flink的Data Source。
消息隊列產品的及格標準：
- 消息的可靠傳遞：確保不丟消息。
- Cluster：支持集羣，確保不會因爲某個節點宕機導致服務不可用，當然也不能丟消息。
- 性能：具備足夠好的性能，能滿足絕大多數場景的性能要求。
二、可供選擇的消息隊列產品
1、RabbitMQ
介紹：
- 使用Erlang語言編寫，最早是爲電信行業系統之間的可靠通訊性設計的，也是少數幾個支持AMQP協議的消息隊列。
- 輕量級、迅速，開箱即用，非常容易部署和使用。
- 有一個特色的功能是支持非常靈活的路由配置。它在生產者和隊列之間增加了一個Exchange模塊，可以理解爲交換機，根據配置的路由規則將生產者發出的消息分發到不同的隊列中。
- 客戶端支持的編程語言是所有消息隊列中最多的。
劣勢：
- 對消息堆積的支持並不好。在它的設計理念中，消息隊列是一個管道，大量的消息積壓不是正常的情況，應當儘量避免。當大量消息積壓時，會導致性能急劇下降。
- RabbitMQ的性能是介紹的幾個消息隊列中最差的，它大概每秒可以處理幾萬到幾十萬條消息，這個性能也足夠支撐絕大多數場景。不過，如果你的應用對消息隊列的性能要求非常高，那就不要選擇RabbitMQ。
- 小衆的編程語言Erlang。如果想基於RabbitMQ做一些擴展和二次開發，建議你慎重考慮可持續維護的問題。
RabbitMQ 官方文檔：https://www.rabbitmq.com/documentation.html
2、RocketMQ
介紹：
- RocketMQ是阿里巴巴2012年開源的產品，後來捐贈給Apache軟件基金會。2017年正式成爲Apache的頂級項目。
- 阿里內部也是使用RocketMQ作爲支撐其業務的消息隊列，經歷多次“雙十一”考驗，它的性能、穩定性和可靠性都是值得信賴的。
- 有非常活躍的中文社區，大多數問題都可以找到中文答案。使用Java語言開發，它的貢獻者大多數爲中國人，源代碼相對比較易懂或易進行擴展和二次開發。
- RocketMQ對在線業務的響應時延做了很多優化，大多數情況下可以做到毫秒級的響應，如果你的應用場景很在意響應時延，那應該選擇使用RocketMQ。
- RocketMQ的性能比RabbitMQ要高一個數量級，每秒大概能處理幾十萬條消息。
劣勢：
- 作爲國產消息隊列，相比國外比較流行的同類產品，與周邊生態系統的集成和兼容程度要略遜一籌。
RocketMQ 官方文檔：https://rocketmq.apache.org/docs/quick-start/
RocketMQ 中國開發者中心：http://rocketmq.cloud/zh-cn/
3、Kafka
介紹：
- 最早是由LinkedIn開發，目前也是Apache的頂級項目。最初的設計目的是用於處理海量的日誌。
- 與周邊生態系統的兼容性是最好的，尤其在大數據和流計算領域，幾乎所有的相關開源軟件系統都會優化支持kafka。
- 使用Scala和Java語言開發，設計上大量使用了批量和異步的思想，這種設計使得Kafka能做到超高的性能，尤其是異步收發性能，是三者中最好。
- 大概每秒可處理幾十萬條消息
劣勢：
- 同步收發消息的響應時延比較高，當你的業務場景中，每秒消息數量沒那麼多時，kafka的時延反而會比較高。所以不太適合在線業務場景。
Kafka 官方文檔：http://kafka.apache.org/documentation/
三、第二梯隊的消息隊列
這些產品之所有沒那麼流行，或多或少都有着比較明顯的短板，不推薦使用，只是作簡單介紹。
1、ActiveMQ
- 最老牌的開源消息隊列，目前已進入老年期，社區不活躍。
- 功能或性能方面都與現代的消息隊列存在明顯的差距，它存在的意義僅限於兼容還在用的爺爺輩系統。
2、ZeroMQ
- 嚴格來說ZeroMQ並不能稱之爲一個消息隊列，而是一個基於消息隊列的多線程網絡庫。
- 如果你需要將消息隊列的功能集成到你的系統進程中，可以考慮使用ZeroMQ。
3、Pulsar
- 一個新興的開源消息隊列產品，最早由Yahoo開發，目前處於成長期，流行度和成熟度相對沒有那麼高。
- 採用存儲和計算分離的設計，有可能會引領未來消息隊列的一個發展方向，建議持續關注這個項目。
四、總結：
選擇的建議：
如果消息隊列並不是將要構建系統的主角之一，對消息隊列功能和性能都沒有很高的要求，只需一個開箱即用易維護的產品，建議使用RabbitMQ。(有良好的運維界面，僅僅只是使用消息隊列功能，用於異步和業務模塊解耦，對性能要求不是很高。rabbitMQ能滿足現階段需求)
- 如果系統使用消息隊列的場景是處理在線業務(在線業務指的是那種服務於web頁面或者APP的服務，這種服務都需要很低的延遲，否則APP就會很卡，體驗不好)，比如在交易系統中用消息隊列傳遞訂單，那RocketMQ的低延遲和金融級的穩定性是你需要的。
- 如果需要處理海量的消息，想收集日誌、監控信息或是前端埋點這類數據，或應用場景大量使用了大數據、流計算(做事後的統計分析)相關的開源產品，那kafka是最適合的