在高并發(fā)業(yè)務場景下仅叫，典型的阿里雙11秒殺等業(yè)務，消息隊列中間件在流量削峰糙捺、解耦上有不可替代的作用诫咱。
之前介紹了《MQ消息隊列的12點核心原理總結》，以及《如何從0到1設計一個MQ消息隊列》洪灯，以及《RPC遠程調用和消息隊列MQ的區(qū)別》坎缭。
今天我們一起來探討：
全量的消息隊列究竟有哪些？ Kafka、RocketMQ幻锁、RabbitMQ的優(yōu)劣勢比較凯亮，以及消息隊列的選型
最全MQ消息隊列有哪些？
那么目前在業(yè)界有哪些比較知名的消息引擎呢哄尔？如下圖所示
這里面幾乎完全列舉了當下比較知名的消息引擎假消，包括：
?ZeroMQ
?推特的Distributedlog
?ActiveMQ：Apache旗下的老牌消息引擎
?RabbitMQ、Kafka：AMQP的默認實現(xiàn)岭接。
?RocketMQ
?Artemis：Apache的ActiveMQ下的子項目
?Apollo：同樣為Apache的ActiveMQ的子項目的號稱下一代消息引擎
?商業(yè)化的消息引擎IronMQ
?以及實現(xiàn)了JMS(Java Message Service)標準的OpenMQ富拗。
MQ消息隊列的技術應用
1.解耦
解耦是消息隊列要解決的最本質問題。
2.最終一致性
最終一致性指的是兩個系統(tǒng)的狀態(tài)保持一致鸣戴，要么都成功啃沪，要么都失敗。
最終一致性不是消息隊列的必備特性窄锅，但確實可以依靠消息隊列來做最終一致性的事情创千。
2.廣播
消息隊列的基本功能之一是進行廣播。
有了消息隊列入偷，我們只需要關心消息是否送達了隊列追驴，至于誰希望訂閱，是下游的事情疏之，無疑極大地減少了開發(fā)和聯(lián)調的工作量殿雪。
3.錯峰與流控
典型的使用場景就是秒殺業(yè)務用于流量削峰場景。
由于篇幅的關系锋爪，本文重點介紹消息隊列比較丙曙，詳細應用場景請參考：《什么是流量削峰？如何解決秒殺業(yè)務的削峰場景》其骄。
Kafka亏镰、RocketMQ、RabbitMQ比較
1.ActiveMQ
優(yōu)點
?單機吞吐量：萬級
?topic數(shù)量都吞吐量的影響：
?時效性：ms級
?可用性：高年栓，基于主從架構實現(xiàn)高可用性
?消息可靠性：有較低的概率丟失數(shù)據(jù)
?功能支持：MQ領域的功能極其完備
缺點:
官方社區(qū)現(xiàn)在對ActiveMQ 5.x維護越來越少拆挥，較少在大規(guī)模吞吐的場景中使用。
2.Kafka
號稱大數(shù)據(jù)的殺手锏某抓，談到大數(shù)據(jù)領域內的消息傳輸纸兔，則繞不開Kafka，這款為大數(shù)據(jù)而生的消息中間件否副，以其百萬級TPS的吞吐量名聲大噪汉矿，迅速成為大數(shù)據(jù)領域的寵兒，在數(shù)據(jù)采集备禀、傳輸洲拇、存儲的過程中發(fā)揮著舉足輕重的作用奈揍。
Apache Kafka它最初由LinkedIn公司基于獨特的設計實現(xiàn)為一個分布式的提交日志系統(tǒng)( a distributed commit log)，之后成為Apache項目的一部分赋续。
目前已經(jīng)被LinkedIn男翰，Uber, Twitter, Netflix等大公司所采納。
優(yōu)點
?性能卓越纽乱，單機寫入TPS約在百萬條/秒蛾绎，最大的優(yōu)點，就是吞吐量高鸦列。
?時效性：ms級
?可用性：非常高租冠，kafka是分布式的，一個數(shù)據(jù)多個副本薯嗤，少數(shù)機器宕機顽爹，不會丟失數(shù)據(jù)，不會導致不可用
?消費者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;
?有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager骆姐；
?在日志領域比較成熟镜粤，被多家公司和多個開源項目使用；
?功能支持：功能較為簡單玻褪，主要支持簡單的MQ功能繁仁，在大數(shù)據(jù)領域的實時計算以及日志采集被大規(guī)模使用
缺點：
?Kafka單機超過64個隊列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象归园，隊列越多，load越高稚矿，發(fā)送消息響應時間變長
?使用短輪詢方式庸诱，實時性取決于輪詢間隔時間；
?消費失敗不支持重試晤揣；
?支持消息順序桥爽，但是一臺代理宕機后，就會產生消息亂序昧识；
?社區(qū)更新較慢钠四；
3.RabbitMQ
RabbitMQ 2007年發(fā)布，是一個在AMQP(高級消息隊列協(xié)議)基礎上完成的跪楞，可復用的企業(yè)消息系統(tǒng)缀去，是當前最主流的消息中間件之一。
RabbitMQ優(yōu)點：
?由于erlang語言的特性甸祭，mq 性能較好缕碎，高并發(fā)；
?吞吐量到萬級池户，MQ功能比較完備??
?健壯咏雌、穩(wěn)定凡怎、易用、跨平臺赊抖、支持多種語言统倒、文檔齊全；
?開源提供的管理界面非常棒氛雪，用起來很好用??
?社區(qū)活躍度高房匆；
RabbitMQ缺點：
?erlang開發(fā)，很難去看懂源碼注暗，基本職能依賴于開源社區(qū)的快速維護和修復bug坛缕，不利于做二次開發(fā)和維護。
?RabbitMQ確實吞吐量會低一些捆昏，這是因為他做的實現(xiàn)機制比較重赚楚。??
?需要學習比較復雜的接口和協(xié)議，學習和維護成本較高骗卜。
4.RocketMQ
RocketMQ出自 阿里公司的開源產品宠页，用 Java 語言實現(xiàn)，在設計時參考了 Kafka寇仓，并做出了自己的一些改進举户。
RocketMQ在阿里集團被廣泛應用在訂單，交易遍烦，充值俭嘁，流計算，消息推送服猪，日志流式處理供填，binglog分發(fā)等場景。
RocketMQ優(yōu)點：
?單機吞吐量：十萬級
?可用性：非常高罢猪，分布式架構
?消息可靠性：經(jīng)過參數(shù)優(yōu)化配置近她，消息可以做到0丟失
?功能支持：MQ功能較為完善，還是分布式的膳帕，擴展性好
?支持10億級別的消息堆積粘捎，不會因為堆積導致性能下降
?源碼是java，我們可以自己閱讀源碼危彩，定制自己公司的MQ攒磨，可以掌控?
RocketMQ缺點：
?支持的客戶端語言不多，目前是java及c++汤徽，其中c++不成熟咧纠；
?社區(qū)活躍度一般
?沒有在 mq 核心中去實現(xiàn)JMS等接口，有些系統(tǒng)要遷移需要修改大量代碼?
消息隊列選擇建議
1.Kafka
Kafka主要特點是基于Pull的模式來處理消息消費泻骤，追求高吞吐量漆羔，一開始的目的就是用于日志收集和傳輸梧奢，適合產生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務的數(shù)據(jù)收集業(yè)務。
大型公司建議可以選用演痒，如果有日志采集功能亲轨，肯定是首選kafka了。
2.RocketMQ
天生為金融互聯(lián)網(wǎng)領域而生鸟顺，對于可靠性要求很高的場景惦蚊，尤其是電商里面的訂單扣款，以及業(yè)務削峰讯嫂，在大量交易涌入時蹦锋，后端可能無法及時處理的情況。
RoketMQ在穩(wěn)定性上可能更值得信賴欧芽，這些業(yè)務場景在阿里雙11已經(jīng)經(jīng)歷了多次考驗莉掂，如果你的業(yè)務有上述并發(fā)場景，建議可以選擇RocketMQ千扔。
3.RabbitMQ
RabbitMQ :結合erlang語言本身的并發(fā)優(yōu)勢憎妙，性能較好，社區(qū)活躍度也比較高曲楚，但是不利于做二次開發(fā)和維護厘唾。不過，RabbitMQ的社區(qū)十分活躍龙誊，可以解決開發(fā)過程中遇到的bug抚垃。
如果你的數(shù)據(jù)量沒有那么大，小公司優(yōu)先選擇功能比較完備的RabbitMQ趟大。
覺得不錯請點贊支持讯柔，歡迎留言或進我的個人群179961551領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】护昧，本群專用于學習交流技術、分享面試機會粗截，拒絕廣告惋耙，我也會在群內不定期答題、探討熊昌。
