常用的幾款訊息佇列的對比
前言
訊息佇列的作用：
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功能，在大資料領域的實時計算以及日誌採集被大規模使用
缺點
由於“攢一波再處理”導致延遲比較高
如何選擇合適的訊息佇列
如果對於訊息佇列的功能和效能要求不是很高，那麼RabbitMQ就夠了，開箱即用。
如果系統使用訊息佇列主要場景是處理線上業務，比如在交易系統中用訊息佇列傳遞訂單，RocketMQ 的低延遲和金融級的穩定性就可以滿足。
要處理海量的訊息，像收集日誌、監控資訊或是前端的埋點這類資料，或是你的應用場景大量使用 了大資料、流計算相關的開源產品，那 Kafka 就是最合適的了。
參考
【訊息佇列及常見訊息佇列介紹】https://cloud.tencent.com/developer/article/1006035
【訊息佇列高手課】https://time.geekbang.org/column/intro/100032301
【訊息佇列Kafka、RocketMQ、RabbitMQ的優劣勢比較】https://zhuanlan.zhihu.com/p/60288391
【Kafka】https://zh.wikipedia.org/wiki/Kafka
【RabbitMQ，RocketMQ，Kafka 幾種訊息佇列的對比】https://boilingfrog.github.io/2021/12/10/幾種常見的訊息佇列的對比/