常用的幾款消息隊列的對比
前言
消息隊列的作用：
1、應用耦合：多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敗；
2、異步處理：多應用對消息隊列中同一消息進行處理，應用間並發處理消息，相比串行處理，減少處理時間；
3、限流削峰：廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；
4、消息驅動的系統：系統分為消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理；
首先選擇消息隊列要滿足以下幾個條件：
1、開源
2、流行
3、兼容性強
消息隊列需要：
1、消息的可靠傳遞：確保不丟消息；
2、Cluster：支持集群，確保不會因為某個節點宕機導致服務不可用，當然也不能丟消息；
3、性能：具備足夠好的性能，能滿足絕大多數場景的性能要求。
RabbitMQ
RabbitMQ 2007年發布，是一個在 AMQP (高級消息隊列協議)基礎上完成的，可復用的企業消息系統，是當前最主流的消息中間件之一。
優點
1、RabbitMQ 的特點 Messaging that just works，“開箱即用的消息隊列”。 RabbitMQ 是一個相對輕量的消息隊列，非常容易部署和使用；
2、多種協議的支持：支持多種消息隊列協議，算的上是最流行的消息隊列之一；
3、靈活的路由配置，和其他消息隊列不同的是，它在生產者 （Producer）和隊列（Queue）之間增加了一個Exchange模塊，你可以理解為交換機。這個Exchange模塊的作用和交換機也非常相似，根據配置的路由規則將生產者發出的消息分發到不同的隊 列中。路由的規則也非常靈活，甚至你可以自己來實現路由規則。
4、健壯、穩定、易用、跨平台、支持多種語言、文檔齊全，RabbitMQ的客戶端支持的編程語言大概是所有消息隊列中最多的；
5、管理界面較豐富，在互聯網公司也有較大規模的應用；
6、社區比較活躍。
缺點
1、RabbitMQ 對消息堆積的處理不好，在它的設計理念里面，消息隊列是一個管道，大量的消息積壓是一種不正常的情況，應當盡量去避免。當大量消息積壓的時候，會導致RabbitMQ的性能急劇下降；
2、性能上有瓶頸，它大概每秒鍾可以處理幾萬到十幾萬條消息，這個對於大多數場景足夠使用了，如果對需求對性能要求非常高，那么就不太合適了。
3、RabbitMQ 使用 Erlang。開發，Erlang 的學習成本還是很高的，如果后期進行二次開發，就不太容易了。
RocketMQ
RocketMQ出自阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進，消息可靠性上比 Kafka 更好。經歷過多次雙十一的考驗，性能和穩定性還是值得信賴的，RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。
優點
1、單機吞吐量：十萬級；
2、可用性：非常高，分布式架構；
3、消息可靠性：經過參數優化配置，消息可以做到0丟失，RocketMQ 的所有消息都是持久化的，先寫入系統 PAGECACHE，然后刷盤，可以保證內存與磁盤都有一份數據；
4、功能支持：MQ功能較為完善，還是分布式的，擴展性好；
5、支持10億級別的消息堆積，不會因為堆積導致性能下降；
6、源碼是java，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控。
缺點
1、支持的客戶端語言不多，目前是 java 及 c++，其中 c++ 不成熟；
2、社區活躍度一般，作為國產的消息隊列，相比國外的比較流行的同類產品，在國際上還沒有那么流行，與周邊生態系統的集成和兼容程度要略遜一籌；
3、沒有在 mq 核心中去實現 JMS 等接口，有些系統要遷移需要修改大量代碼。
Kafka
Apache Kafka是一個分布式消息發布訂閱系統。它最初由LinkedIn公司基於獨特的設計實現為一個分布式的提交日志系統( a distributed commit log)，之后成為Apache項目的一部分。
這是一款為大數據而生的消息中間件，在數據采集、傳輸、存儲的過程中發揮着舉足輕重的作用。
優點
1、性能卓越，單機寫入TPS約在百萬條/秒，最大的優點，就是吞吐量高；
2、性能卓越，單機寫入TPS約在百萬條/秒，消息大小10個字節；
3、可用性：非常高，kafka是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用；
4、消費者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;
5、有優秀的第三方Kafka Web管理界面Kafka-Manager；
6、在日志領域比較成熟，被多家公司和多個開源項目使用；
7、功能支持：功能較為簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日志采集被大規模使用
缺點
由於“攢一波再處理”導致延遲比較高
Pulsar
Pulsar 是一個用於服務器到服務器的消息系統，具有多租戶、高性能等優勢。 Pulsar 最初由 Yahoo 開發，目前由 Apache 軟件基金會管理。
優點
1、更多功能：Pulsar Function、多租戶、Schema registry、n 層存儲、多種消費模式和持久性模式等；
2、Pulsar 的單個實例原生支持多個集群，可跨機房在集群間無縫地完成消息復制；
3、極低的發布延遲和端到端延遲；
4、可無縫擴展到超過一百萬個 topic；
5、簡單的客戶端 API，支持 Java、Go、Python 和 C++。
6、Pulsar 的單個實例原生支持多個集群，可跨機房在集群間無縫地完成消息復制。
缺點
正處於成長期，流行度和成熟度相對沒有那么高
如何選擇合適的消息隊列
如果對於消息隊列的功能和性能要求不是很高，那么RabbitMQ就夠了，開箱即用。
如果系統使用消息隊列主要場景是處理在線業務，比如在交易系統中用消息隊列傳遞訂單，RocketMQ 的低延遲和金融級的穩定性就可以滿足。
要處理海量的消息，像收集日志、監控信息或是前端的埋點這類數據，或是你的應用場景大量使用 了大數據、流計算相關的開源產品，那 Kafka 就是最合適的了。
如果數據量很大，同時不希望有 Kafka 的高延遲，剛好業務場景是金融場景。RocketMQ 對 Topic 運營不太友好，特別是不支持按 Topic 刪除失效消息，以及不具備宕機 Failover 能力。那么 Pulsar 可能就是你的一個選擇了。
參考
【消息隊列及常見消息隊列介紹】https://cloud.tencent.com/developer/article/1006035
【消息隊列高手課】https://time.geekbang.org/column/intro/100032301
【消息隊列Kafka、RocketMQ、RabbitMQ的優劣勢比較】https://zhuanlan.zhihu.com/p/60288391
【Pulsar 概述】https://pulsar.apache.org/docs/zh-CN/next/concepts-overview/
【Apache Pulsar 在騰訊計費場景下的應用】https://www.infoq.cn/article/qvxrkboa_7h0g6viptyl
【Kafka】https://zh.wikipedia.org/wiki/Kafka
【RabbitMQ，RocketMQ，Kafka，Pulsar 幾種消息隊列的對比】https://boilingfrog.github.io/2021/12/10/幾種常見的消息隊列的對比/