消息隊列及常見消息隊列介紹

導語 ： 消息隊列是分布式系統(tǒng)中重要的組件逗宜，在很多生產環(huán)境如商品搶購等需要控制并發(fā)量的場景下都需要用到。最近組內需要做流水server的選型升級微峰，這里對消息隊列及常見的消息隊列進行了一次調研司忱，整理了相關資料蜡峰，分享給大家。

一最筒、消息隊列(MQ)概述

消息隊列（Message Queue）贺氓，是分布式系統(tǒng)中重要的組件，其通用的使用場景可以簡單地描述為：

當不需要立即獲得結果床蜘，但是并發(fā)量又需要進行控制的時候辙培，差不多就是需要使用消息隊列的時候。

消息隊列主要解決了應用耦合邢锯、異步處理扬蕊、流量削鋒等問題。

當前使用較多的消息隊列有RabbitMQ丹擎、RocketMQ尾抑、ActiveMQ歇父、Kafka、ZeroMQ再愈、MetaMq等榜苫，而部分數(shù)據(jù)庫如Redis、Mysql以及phxsql也可實現(xiàn)消息隊列的功能翎冲。

二垂睬、消息隊列使用場景

消息隊列在實際應用中包括如下四個場景：

• 應用耦合：多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敻省羔飞；
• 異步處理：多應用對消息隊列中同一消息進行處理，應用間并發(fā)處理消息檐春，相比串行處理逻淌，減少處理時間；
• 限流削峰：廣泛應用于秒殺或搶購活動中疟暖，避免流量過大導致應用系統(tǒng)掛掉的情況卡儒；
• 消息驅動的系統(tǒng)：系統(tǒng)分為消息隊列阐肤、消息生產者磷仰、消息消費者乙各，生產者負責產生消息昏鹃，消費者(可能有多個)負責對消息進行處理潮改；

下面詳細介紹上述四個場景以及消息隊列如何在上述四個場景中使用：

2.1 異步處理

具體場景：用戶為了使用某個應用葱轩，進行注冊腺阳，系統(tǒng)需要發(fā)送注冊郵件并驗證短信炕贵。對這兩個操作的處理方式有兩種：串行及并行缘圈。

（1）串行方式：新注冊信息生成后劣光，先發(fā)送注冊郵件，再發(fā)送驗證短信糟把；

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

在這種方式下绢涡，需要最終發(fā)送驗證短信后再返回給客戶端。

（2）并行處理：新注冊信息寫入后遣疯，由發(fā)短信和發(fā)郵件并行處理雄可；

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

在這種方式下，發(fā)短信和發(fā)郵件 需處理完成后再返回給客戶端缠犀。

假設以上三個子系統(tǒng)處理的時間均為50ms数苫，且不考慮網絡延遲，則總的處理時間：

串行：50+50+50=150ms 并行：50+50 = 100ms

若使用消息隊列：

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

并在寫入消息隊列后立即返回成功給客戶端辨液，則總的響應時間依賴于寫入消息隊列的時間文判，而寫入消息隊列的時間本身是可以很快的，基本可以忽略不計室梅，因此總的處理時間相比串行提高了2倍戏仓，相比并行提高了一倍疚宇；

2.2 應用耦合

具體場景：用戶使用QQ相冊上傳一張圖片，人臉識別系統(tǒng)會對該圖片進行人臉識別赏殃，一般的做法是敷待，服務器接收到圖片后，圖片上傳系統(tǒng)立即調用人臉識別系統(tǒng)仁热，調用完成后再返回成功榜揖，如下圖所示：

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

該方法有如下缺點：

• 人臉識別系統(tǒng)被調失敗，導致圖片上傳失斂勾馈举哟；
• 延遲高，需要人臉識別系統(tǒng)處理完成后迅矛，再返回給客戶端妨猩，即使用戶并不需要立即知道結果；
• 圖片上傳系統(tǒng)與人臉識別系統(tǒng)之間互相調用秽褒，需要做耦合壶硅；

若使用消息隊列：

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

客戶端上傳圖片后，圖片上傳系統(tǒng)將圖片信息如uin销斟、批次寫入消息隊列庐椒，直接返回成功；而人臉識別系統(tǒng)則定時從消息隊列中取數(shù)據(jù)蚂踊，完成對新增圖片的識別约谈。

此時圖片上傳系統(tǒng)并不需要關心人臉識別系統(tǒng)是否對這些圖片信息的處理、以及何時對這些圖片信息進行處理犁钟。事實上棱诱，由于用戶并不需要立即知道人臉識別結果，人臉識別系統(tǒng)可以選擇不同的調度策略特纤，按照閑時、忙時侥加、正常時間捧存，對隊列中的圖片信息進行處理。

2.3 限流削峰

具體場景：購物網站開展秒殺活動担败，一般由于瞬時訪問量過大昔穴，服務器接收過大，會導致流量暴增提前，相關系統(tǒng)無法處理請求甚至崩潰吗货。而加入消息隊列后，系統(tǒng)可以從消息隊列中取數(shù)據(jù)狈网，相當于消息隊列做了一次緩沖宙搬。

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

該方法有如下優(yōu)點：

1. 請求先入消息隊列笨腥，而不是由業(yè)務處理系統(tǒng)直接處理，做了一次緩沖,極大地減少了業(yè)務處理系統(tǒng)的壓力勇垛；
2. 隊列長度可以做限制脖母，事實上，秒殺時闲孤，后入隊列的用戶無法秒殺到商品谆级，這些請求可以直接被拋棄，返回活動已結束或商品已售完信息讼积；

2.4 消息驅動的系統(tǒng)

具體場景：用戶新上傳了一批照片肥照， 人臉識別系統(tǒng)需要對這個用戶的所有照片進行聚類，聚類完成后由對賬系統(tǒng)重新生成用戶的人臉索引(加快查詢)勤众。這三個子系統(tǒng)間由消息隊列連接起來舆绎，前一個階段的處理結果放入隊列中，后一個階段從隊列中獲取消息繼續(xù)處理决摧。

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

該方法有如下優(yōu)點：

• 避免了直接調用下一個系統(tǒng)導致當前系統(tǒng)失斠谡簟掌桩；
• 每個子系統(tǒng)對于消息的處理方式可以更為靈活，可以選擇收到消息時就處理茅坛，可以選擇定時處理，也可以劃分時間段按不同處理速度處理则拷；

三、消息隊列的兩種模式

消息隊列包括兩種模式煌茬，點對點模式（point to point， queue）和發(fā)布/訂閱模式（publish/subscribe坛善，topic）晾蜘。

3.1 點對點模式

點對點模式下包括三個角色：

• 消息隊列
• 發(fā)送者 (生產者)
• 接收者（消費者）

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

消息發(fā)送者生產消息發(fā)送到queue中眠屎，然后消息接收者從queue中取出并且消費消息。消息被消費以后岖常，queue中不再有存儲葫督，所以消息接收者不可能消費到已經被消費的消息板惑。

點對點模式特點：

• 每個消息只有一個接收者（Consumer）(即一旦被消費笼蛛，消息就不再在消息隊列中)滨砍；
• 發(fā)送者和接收者間沒有依賴性，發(fā)送者發(fā)送消息之后领追，不管有沒有接收者在運行响逢，都不會影響到發(fā)送者下次發(fā)送消息；
• 接收者在成功接收消息之后需向隊列應答成功些膨，以便消息隊列刪除當前接收的消息钦铺；

3.2 發(fā)布/訂閱模式

發(fā)布/訂閱模式下包括三個角色：

• 角色主題（Topic）
• 發(fā)布者(Publisher)
• 訂閱者(Subscriber)

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

發(fā)布者將消息發(fā)送到Topic,系統(tǒng)將這些消息傳遞給多個訂閱者。

發(fā)布/訂閱模式特點：

• 每個消息可以有多個訂閱者矛洞；
• 發(fā)布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者噩峦，它必須創(chuàng)建一個訂閱者之后抽兆，才能消費發(fā)布者的消息。
• 為了消費消息凭涂，訂閱者需要提前訂閱該角色主題导盅，并保持在線運行揍瑟；

四乍炉、常用消息隊列介紹

本部分主要介紹四種常用的消息隊列（RabbitMQ/ActiveMQ/RocketMQ/Kafka）的主要特性、優(yōu)點巢株、缺點熙涤。

4.1 RabbitMQ

RabbitMQ 2007年發(fā)布祠挫，是一個在AMQP(高級消息隊列協(xié)議)基礎上完成的，可復用的企業(yè)消息系統(tǒng)骚灸，是當前最主流的消息中間件之一慌植。

主要特性：

1. 可靠性: 提供了多種技術可以讓你在性能和可靠性之間進行權衡蝶柿。這些技術包括持久性機制、投遞確認著恩、發(fā)布者證實和高可用性機制蜻展；
2. 靈活的路由： 消息在到達隊列前是通過交換機進行路由的纵顾。RabbitMQ為典型的路由邏輯提供了多種內置交換機類型。如果你有更復雜的路由需求敷矫，可以將這些交換機組合起來使用汉额，你甚至可以實現(xiàn)自己的交換機類型蠕搜，并且當做RabbitMQ的插件來使用；
3. 消息集群：在相同局域網中的多個RabbitMQ服務器可以聚合在一起轨蛤，作為一個獨立的邏輯代理來使用；
4. 隊列高可用：隊列可以在集群中的機器上進行鏡像圃验，以確保在硬件問題下還保證消息安全澳窑；
5. 多種協(xié)議的支持：支持多種消息隊列協(xié)議供常；
6. 服務器端用Erlang語言編寫话侧，支持只要是你能想到的所有編程語言；
7. 管理界面: RabbitMQ有一個易用的用戶界面悲立，使得用戶可以監(jiān)控和管理消息Broker的許多方面新博；
8. 跟蹤機制：如果消息異常赫悄，RabbitMQ提供消息跟蹤機制，使用者可以找出發(fā)生了什么姑隅；
9. 插件機制：提供了許多插件讲仰，來從多方面進行擴展痪蝇，也可以編寫自己的插件躏啰；

使用RabbitMQ需要：

• ErLang語言包
• RabbitMQ安裝包

RabbitMQ可以運行在Erlang語言所支持的平臺之上：

Solaris

BSD

Linux

MacOSX

TRU64

Windows NT/2000/XP/Vista/Windows 7/Windows 8

Windows Server 2003/2008/2012

Windows 95, 98

VxWorks

優(yōu)點：

1. 由于erlang語言的特性，mq 性能較好毫捣，高并發(fā)；
2. 健壯、穩(wěn)定牌柄、易用侧甫、跨平臺披粟、支持多種語言、文檔齊全惑艇；
3. 有消息確認機制和持久化機制滨巴，可靠性高俺叭；
4. 高度可定制的路由熄守；
5. 管理界面較豐富，在互聯(lián)網公司也有較大規(guī)模的應用攒发；
6. 社區(qū)活躍度高晨继；

缺點：

1. 盡管結合erlang語言本身的并發(fā)優(yōu)勢搬俊，性能較好唉擂，但是不利于做二次開發(fā)和維護；
2. 實現(xiàn)了代理架構腹缩，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點上排隊。此特性使得RabbitMQ易于使用和部署润讥，但是使得其運行速度較慢楚殿，因為中央節(jié)點增加了延遲竿痰，消息封裝后也比較大影涉；
3. 需要學習比較復雜的接口和協(xié)議，學習和維護成本較高匣缘；

4.2 ActiveMQ

ActiveMQ是由Apache出品孵户，ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)岔留。它非诚琢快速，支持多種語言的客戶端和協(xié)議进胯，而且可以非常容易的嵌入到企業(yè)的應用環(huán)境中胁镐，并有許多高級功能诸衔。

主要特性：

1. 服從 JMS 規(guī)范：JMS 規(guī)范提供了良好的標準和保證笨农，包括：同步或異步的消息分發(fā)，一次和僅一次的消息分發(fā)竭宰，消息接收和訂閱等等切揭。遵從 JMS 規(guī)范的好處在于，不論使用什么 JMS 實現(xiàn)提供者哼审，這些基礎特性都是可用的；
2. 連接性：ActiveMQ 提供了廣泛的連接選項巩步，支持的協(xié)議有：HTTP/S桦踊，IP 多播籍胯，SSL，STOMP炼蛤，TCP理朋，UDP嗽上，XMPP等等熄攘。對眾多協(xié)議的支持讓 ActiveMQ 擁有了很好的靈活性挪圾。
3. 支持的協(xié)議種類多：OpenWire、STOMP惯殊、REST土思、XMPP、AMQP 崎岂；
4. 持久化插件和安全插件：ActiveMQ 提供了多種持久化選擇冲甘。而且途样，ActiveMQ 的安全性也可以完全依據(jù)用戶需求進行自定義鑒權和授權何暇；
5. 支持的客戶端語言種類多：除了 Java 之外裆站，還有：C/C++，.NET羽嫡，Perl杭棵，PHP氛赐，Python鹰祸，Ruby蛙婴；
6. 代理集群：多個 ActiveMQ 代理可以組成一個集群來提供服務；
7. 異常簡單的管理：ActiveMQ 是以開發(fā)者思維被設計的浇衬。所以耘擂，它并不需要專門的管理員絮姆，因為它提供了簡單又使用的管理特性。有很多中方法可以監(jiān)控 ActiveMQ 不同層面的數(shù)據(jù)铃绒，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX颠悬，通過處理 JMX 的告警消息定血，通過使用命令行腳本澜沟，甚至可以通過監(jiān)控各種類型的日志倔喂。

使用ActiveMQ需要：

• Java JDK
• ActiveMQ安裝包

ActiveMQ可以運行在Java語言所支持的平臺之上席噩。

優(yōu)點：

1. 跨平臺(JAVA編寫與平臺無關有贤壁，ActiveMQ幾乎可以運行在任何的JVM上)
2. 可以用JDBC：可以將數(shù)據(jù)持久化到數(shù)據(jù)庫脾拆。雖然使用JDBC會降低ActiveMQ的性能名船，但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲介質。將消息存到數(shù)據(jù)庫蜈块，看得見摸得著百揭。而且公司有專門的DBA去對數(shù)據(jù)庫進行調優(yōu)器一，主從分離厨内；
3. 支持JMS ：支持JMS的統(tǒng)一接口;
4. 支持自動重連；
5. 有安全機制：支持基于shiro癣亚，jaas等多種安全配置機制述雾，可以對Queue/Topic進行認證和授權兼丰。
6. 監(jiān)控完善：擁有完善的監(jiān)控鳍征，包括Web Console艳丛，JMX氮双，Shell命令行，Jolokia的REST API送爸；
7. 界面友善：提供的Web Console可以滿足大部分情況袭厂，還有很多第三方的組件可以使用纹磺，如hawtio橄杨；

缺點：

1. 社區(qū)活躍度不及RabbitMQ高乾忱；
2. 根據(jù)其他用戶反饋窄瘟，會出莫名其妙的問題蹄葱，會丟失消息；
3. 目前重心放到activemq6.0產品-apollo惯悠，對5.x的維護較少克婶；
4. 不適合用于上千個隊列的應用場景情萤；

4.3 RocketMQ

RocketMQ出自 阿里公司的開源產品筋岛，用 Java 語言實現(xiàn)睁宰，在設計時參考了 Kafka柒傻，并做出了自己的一些改進，消息可靠性上比 Kafka 更好寒锚。RocketMQ在阿里集團被廣泛應用在訂單，交易雌桑，充值校坑，流計算千诬，消息推送徐绑，日志流式處理傲茄，binglog分發(fā)等場景。

主要特性：

1. 是一個隊列模型的消息中間件蟆融，具有高性能型酥、高可靠冕末、高實時、分布式特點侣颂；
2. Producer档桃、Consumer、隊列都可以分布式憔晒；
3. Producer向一些隊列輪流發(fā)送消息藻肄，隊列集合稱為Topic，Consumer如果做廣播消費拒担，則一個consumer實例消費這個Topic對應的所有隊列嘹屯，如果做集群消費从撼，則多個Consumer實例平均消費這個topic對應的隊列集合州弟；
4. 能夠保證嚴格的消息順序；
5. 提供豐富的消息拉取模式低零；
6. 高效的訂閱者水平擴展能力婆翔；
7. 實時的消息訂閱機制；
8. 億級消息堆積能力掏婶；
9. 較少的依賴啃奴；

使用RocketMQ需要：

• Java JDK
• 安裝git、Maven
• RocketMQ安裝包

RocketMQ可以運行在Java語言所支持的平臺之上雄妥。

優(yōu)點：

1. 單機支持 1 萬以上持久化隊列
2. RocketMQ 的所有消息都是持久化的最蕾，先寫入系統(tǒng) PAGECACHE，然后刷盤老厌，可以保證內存與磁盤都有一份數(shù)據(jù)瘟则，

訪問時，直接從內存讀取枝秤。

1. 模型簡單醋拧，接口易用（JMS 的接口很多場合并不太實用）；
2. 性能非常好，可以大量堆積消息在broker中趁仙；
3. 支持多種消費洪添，包括集群消費、廣播消費等雀费。
4. 各個環(huán)節(jié)分布式擴展設計干奢，主從HA；
5. 開發(fā)度較活躍盏袄，版本更新很快忿峻。

缺點：

支持的客戶端語言不多，目前是java及c++辕羽，其中c++不成熟逛尚；

RocketMQ社區(qū)關注度及成熟度也不及前兩者；

沒有web管理界面刁愿，提供了一個CLI(命令行界面)管理工具帶來查詢绰寞、管理和診斷各種問題；

沒有在 mq 核心中去實現(xiàn)JMS等接口铣口；

4.4 Kafka

Apache Kafka是一個分布式消息發(fā)布訂閱系統(tǒng)滤钱。它最初由LinkedIn公司基于獨特的設計實現(xiàn)為一個分布式的提交日志系統(tǒng)( a distributed commit log)，脑题，之后成為Apache項目的一部分件缸。Kafka系統(tǒng)快速、可擴展并且可持久化叔遂。它的分區(qū)特性他炊，可復制和可容錯都是其不錯的特性。

主要特性：

1. 快速持久化已艰，可以在O(1)的系統(tǒng)開銷下進行消息持久化痊末；
2. 高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率旗芬；
3. .完全的分布式系統(tǒng)舌胶，Broker捆蜀、Producer疮丛、Consumer都原生自動支持分布式，自動實現(xiàn)負載均衡辆它；
4. 支持同步和異步復制兩種HA誊薄；
5. 支持數(shù)據(jù)批量發(fā)送和拉取锰茉；
6. zero-copy：減少IO操作步驟呢蔫；
7. 數(shù)據(jù)遷移、擴容對用戶透明；
8. 無需停機即可擴展機器片吊；
9. 其他特性：嚴格的消息順序绽昏、豐富的消息拉取模型、高效訂閱者水平擴展俏脊、實時的消息訂閱全谤、億級的消息堆積能力、定期刪除機制爷贫；

使用Kafka需要：

• Java JDK
• Kafka安裝包

優(yōu)點：

1. 客戶端語言豐富认然，支持java、.net漫萄、php卷员、ruby、python腾务、go等多種語言毕骡；
2. 性能卓越，單機寫入TPS約在百萬條/秒岩瘦，消息大小10個字節(jié)挺峡；
3. 提供完全分布式架構, 并有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積；
4. 支持批量操作担钮；
5. 消費者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費且僅被消費一次;
6. 有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager橱赠；
7. 在日志領域比較成熟，被多家公司和多個開源項目使用箫津；

缺點：

1. Kafka單機超過64個隊列/分區(qū)狭姨，Load會發(fā)生明顯的飆高現(xiàn)象，隊列越多苏遥，load越高饼拍，發(fā)送消息響應時間變長
2. 使用短輪詢方式，實時性取決于輪詢間隔時間田炭；
3. 消費失敗不支持重試师抄；
4. 支持消息順序，但是一臺代理宕機后教硫，就會產生消息亂序叨吮；
5. 社區(qū)更新較慢；

4.5 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

這里列舉了上述四種消息隊列的差異對比：

<figure style="box-sizing: border-box; list-style: inherit; margin: 20px 0px; display: block; text-align: center;">

image

</figure>

結論:

Kafka在于分布式架構瞬矩，RabbitMQ基于AMQP協(xié)議來實現(xiàn)茶鉴，RocketMQ/思路來源于kafka，改成了主從結構景用，在事務性可靠性方面做了優(yōu)化涵叮。廣泛來說，電商、金融等對事務性要求很高的割粮，可以考慮RabbitMQ和RocketMQ盾碗，對性能要求高的可考慮Kafka。

五舀瓢、參考資料：

5.1 消息隊列：

1. 大型網站架構之分布式消息隊列 http://blog.csdn.net/shaobingj126/article/details/50585035
2. 消息隊列的使用場景 https://www.zhihu.com/question/34243607/answer/127666030
3. 淺談異步消息隊列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html
4. 消息隊列的兩種模式 http://blog.csdn.net/heyutao007/article/details/50131089

5.2 RabbitMQ

1. RabbitMQ主頁 https://www.rabbitmq.com/
2. RabbitMQ學習教程 https://www.rabbitmq.com/getstarted.html
3. 專欄:RabbitMQ從入門到精通 http://blog.csdn.net/column/details/rabbitmq.html
4. RabbitMQ能為你做些什么 http://rabbitmq.mr-ping.com/description.html
5. RabbitMQ指南(1)-特性及功能 https://blog.zenfery.cc/archives/79.html

5.3 ActiveMQ

1. ActiveMQ主頁 http://activemq.apache.org/
2. Apache ActiveMQ介紹 http://jfires.iteye.com/blog/1187688
3. ActiveMQ的簡介與安裝 http://blog.csdn.net/sl1992/article/details/72824562
4. ActiveMQ 和消息簡介 http://www.cnblogs.com/craftsman-gao/p/7002605.html

5.4 RocketMQ

1. 主頁 https://github.com/alibaba/RocketMQ
2. RocketMQ 原理簡介 http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf
3. RocketMQ與kafka對比（18項差異） http://jm.taobao.org/2016/03/24/rmq-vs-kafka/

5.5 Kafka

1.Kafka主頁： http://kafka.apache.org/

1. Kafka特性 http://www.cnblogs.com/lsx1993/p/4847719.html
2. Kafka客戶端支持語言 https://cwiki.apache.org/confluence/display/KAFKA/Clients

5.6 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

1. RocketMQ置尔，隊列選型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/
2. RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html
3. 即時通信RabbitMQ二-性能測試 http://www.reibang.com/p/d31ae9e3bfb6
4. RabbitMq、ActiveMq氢伟、ZeroMq榜轿、kafka之間的比較,資料匯總 http://blog.csdn.net/linsongbin1/article/details/47781187
5. 消息隊列軟件產品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html

總結：

消息隊列利用高效可靠的消息傳遞機制進行平臺無關的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成朵锣。目前業(yè)界有很多的MQ產品谬盐，例如RabbitMQ、RocketMQ诚些、ActiveMQ飞傀、Kafka、ZeroMQ诬烹、MetaMq等砸烦，也有直接使用數(shù)據(jù)庫redis充當消息隊列的案例。而這些消息隊列產品绞吁，各有側重幢痘，在實際選型時，需要結合自身需求及MQ產品特征家破，綜合考慮颜说。