消息中间件系列(八)：Kafka、RocketMQ、RabbitMQ等的优劣势比较
在高并發業務場景下，典型的阿里雙11秒殺等業務，消息隊列中間件在流量削峰、解耦上有不可替代的作用。
之前介紹了MQ消息隊列的12點核心原理總結，以及如何從0到1設計一個MQ消息隊列，以及RPC遠程調用和消息隊列MQ的區別
今天我們一起來探討：
最全MQ消息隊列有哪些
那么目前在業界有哪些比較知名的消息引擎呢？如下圖所示
這里面幾乎完全列舉了當下比較知名的消息引擎，包括：
MQ消息隊列的技術應用
1.解耦
解耦是消息隊列要解決的最本質問題。
2.最終一致性
最終一致性指的是兩個系統的狀態保持一致，要么都成功，要么都失敗。
最終一致性不是消息隊列的必備特性，但確實可以依靠消息隊列來做最終一致性的事情。
2.廣播
消息隊列的基本功能之一是進行廣播。
有了消息隊列，我們只需要關心消息是否送達了隊列，至于誰希望訂閱，是下游的事情，無疑極大地減少了開發和聯調的工作量。
3.錯峰與流控
典型的使用場景就是秒殺業務用于流量削峰場景。
由于篇幅的關系，本文重點介紹消息隊列比較，詳細應用場景請參考：什么是流量削峰？如何解決秒殺業務的削峰場景
Kafka、RocketMQ、RabbitMQ比較
1.ActiveMQ
優點
- 單機吞吐量：萬級
- topic數量都吞吐量的影響：
- 時效性：ms級
- 可用性：高，基于主從架構實現高可用性
- 消息可靠性：有較低的概率丟失數據
- 功能支持：MQ領域的功能極其完備
缺點:
官方社區現在對ActiveMQ 5.x維護越來越少，較少在大規模吞吐的場景中使用。
2.Kafka
號稱大數據的殺手锏，談到大數據領域內的消息傳輸，則繞不開Kafka，這款為大數據而生的消息中間件，以其百萬級TPS的吞吐量名聲大噪，迅速成為大數據領域的寵兒，在數據采集、傳輸、存儲的過程中發揮著舉足輕重的作用。
Apache Kafka它最初由LinkedIn公司基于獨特的設計實現為一個分布式的提交日志系統（ a distributed commit log），之后成為Apache項目的一部分。
目前已經被LinkedIn，Uber, Twitter, Netflix等大公司所采納。
優點
- 性能卓越，單機寫入TPS約在百萬條/秒，最大的優點，就是吞吐量高。
- 時效性：ms級
- 可用性：非常高，kafka是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
- 消費者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;
- 有優秀的第三方Kafka Web管理界面Kafka-Manager；
- 在日志領域比較成熟，被多家公司和多個開源項目使用；
- 功能支持：功能較為簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日志采集被大規模使用
缺點：
3.RabbitMQ
RabbitMQ 2007年發布，是一個在AMQP（高級消息隊列協議）基礎上完成的，可復用的企業消息系統，是當前最主流的消息中間件之一。
RabbitMQ優點：
RabbitMQ缺點：
4.RocketMQ
RocketMQ出自 阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，并做出了自己的一些改進。
RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發等場景。
RocketMQ優點：
RocketMQ缺點：
消息隊列選擇建議
1.Kafka
Kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。
大型公司建議可以選用，如果有日志采集功能，肯定是首選kafka了。
2.RocketMQ
天生為金融互聯網領域而生，對于可靠性要求很高的場景，尤其是電商里面的訂單扣款，以及業務削峰，在大量交易涌入時，后端可能無法及時處理的情況。
RoketMQ在穩定性上可能更值得信賴，這些業務場景在阿里雙11已經經歷了多次考驗，如果你的業務有上述并發場景，建議可以選擇RocketMQ。
3.RabbitMQ
RabbitMQ :結合erlang語言本身的并發優勢，性能較好，社區活躍度也比較高，但是不利于做二次開發和維護。不過，RabbitMQ的社區十分活躍，可以解決開發過程中遇到的bug。
如果你的數據量沒有那么大，小公司優先選擇功能比較完備的RabbitMQ。
你可能也喜歡:
總結
以上是生活随笔為你收集整理的消息中间件系列(八)：Kafka、RocketMQ、RabbitMQ等的优劣势比较的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring Boot 2.2 正式发布
- 下一篇： 美团点评移动端基础日志库——Logan