一特姐、消息隊(duì)列(MQ)概述

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

當(dāng)不需要立即獲得結(jié)果藕坯，但是并發(fā)量又需要進(jìn)行控制的時(shí)候，差不多就是需要使用消息隊(duì)列的時(shí)候宙攻。

消息隊(duì)列主要解決了應(yīng)用耦合奠货、異步處理、流量削鋒等問題座掘。

當(dāng)前使用較多的消息隊(duì)列有RabbitMQ递惋、RocketMQ柔滔、ActiveMQ、Kafka萍虽、ZeroMQ睛廊、MetaMq等，而部分?jǐn)?shù)據(jù)庫如Redis杉编、Mysql以及phxsql也可實(shí)現(xiàn)消息隊(duì)列的功能超全。

二、消息隊(duì)列使用場景

消息隊(duì)列在實(shí)際應(yīng)用中包括如下四個(gè)場景：

• 應(yīng)用耦合：多應(yīng)用間通過消息隊(duì)列對(duì)同一消息進(jìn)行處理邓馒，避免調(diào)用接口失敗導(dǎo)致整個(gè)過程失斔恢臁；

• 異步處理：多應(yīng)用對(duì)消息隊(duì)列中同一消息進(jìn)行處理光酣，應(yīng)用間并發(fā)處理消息疏遏，相比串行處理，減少處理時(shí)間救军；

• 限流削峰：廣泛應(yīng)用于秒殺或搶購活動(dòng)中财异，避免流量過大導(dǎo)致應(yīng)用系統(tǒng)掛掉的情況；

• 消息驅(qū)動(dòng)的系統(tǒng)：系統(tǒng)分為消息隊(duì)列唱遭、消息生產(chǎn)者戳寸、消息消費(fèi)者，生產(chǎn)者負(fù)責(zé)產(chǎn)生消息拷泽，消費(fèi)者(可能有多個(gè))負(fù)責(zé)對(duì)消息進(jìn)行處理疫鹊；

下面詳細(xì)介紹上述四個(gè)場景以及消息隊(duì)列如何在上述四個(gè)場景中使用：

2.1 異步處理

具體場景：用戶為了使用某個(gè)應(yīng)用，進(jìn)行注冊(cè)跌穗，系統(tǒng)需要發(fā)送注冊(cè)郵件并驗(yàn)證短信订晌。對(duì)這兩個(gè)操作的處理方式有兩種：串行及并行。

（1）串行方式：新注冊(cè)信息生成后蚌吸，先發(fā)送注冊(cè)郵件锈拨，再發(fā)送驗(yàn)證短信；

image

在這種方式下羹唠，需要最終發(fā)送驗(yàn)證短信后再返回給客戶端奕枢。

（2）并行處理：新注冊(cè)信息寫入后，由發(fā)短信和發(fā)郵件并行處理佩微；

image

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

假設(shè)以上三個(gè)子系統(tǒng)處理的時(shí)間均為50ms哺眯，且不考慮網(wǎng)絡(luò)延遲谷浅，則總的處理時(shí)間：

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

若使用消息隊(duì)列：

image

并在寫入消息隊(duì)列后立即返回成功給客戶端，則總的響應(yīng)時(shí)間依賴于寫入消息隊(duì)列的時(shí)間，而寫入消息隊(duì)列的時(shí)間本身是可以很快的一疯，基本可以忽略不計(jì)撼玄，因此總的處理時(shí)間相比串行提高了2倍，相比并行提高了一倍墩邀；

2.2 應(yīng)用耦合

具體場景：用戶使用QQ相冊(cè)上傳一張圖片掌猛，人臉識(shí)別系統(tǒng)會(huì)對(duì)該圖片進(jìn)行人臉識(shí)別，一般的做法是眉睹，服務(wù)器接收到圖片后荔茬，圖片上傳系統(tǒng)立即調(diào)用人臉識(shí)別系統(tǒng)，調(diào)用完成后再返回成功竹海，如下圖所示：

image

該方法有如下缺點(diǎn)：

• 人臉識(shí)別系統(tǒng)被調(diào)失敗慕蔚，導(dǎo)致圖片上傳失敗站削；

• 延遲高坊萝，需要人臉識(shí)別系統(tǒng)處理完成后，再返回給客戶端许起，即使用戶并不需要立即知道結(jié)果；

• 圖片上傳系統(tǒng)與人臉識(shí)別系統(tǒng)之間互相調(diào)用菩鲜，需要做耦合园细；

若使用消息隊(duì)列：

image

客戶端上傳圖片后，圖片上傳系統(tǒng)將圖片信息如uin接校、批次寫入消息隊(duì)列猛频，直接返回成功；而人臉識(shí)別系統(tǒng)則定時(shí)從消息隊(duì)列中取數(shù)據(jù)蛛勉，完成對(duì)新增圖片的識(shí)別鹿寻。
此時(shí)圖片上傳系統(tǒng)并不需要關(guān)心人臉識(shí)別系統(tǒng)是否對(duì)這些圖片信息的處理、以及何時(shí)對(duì)這些圖片信息進(jìn)行處理诽凌。事實(shí)上毡熏，由于用戶并不需要立即知道人臉識(shí)別結(jié)果，人臉識(shí)別系統(tǒng)可以選擇不同的調(diào)度策略侣诵，按照閑時(shí)痢法、忙時(shí)、正常時(shí)間杜顺，對(duì)隊(duì)列中的圖片信息進(jìn)行處理财搁。

2.3 限流削峰

具體場景：購物網(wǎng)站開展秒殺活動(dòng)，一般由于瞬時(shí)訪問量過大躬络，服務(wù)器接收過大尖奔，會(huì)導(dǎo)致流量暴增，相關(guān)系統(tǒng)無法處理請(qǐng)求甚至崩潰。而加入消息隊(duì)列后提茁，系統(tǒng)可以從消息隊(duì)列中取數(shù)據(jù)淹禾，相當(dāng)于消息隊(duì)列做了一次緩沖。

image

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

1. 請(qǐng)求先入消息隊(duì)列甘凭，而不是由業(yè)務(wù)處理系統(tǒng)直接處理稀拐，做了一次緩沖,極大地減少了業(yè)務(wù)處理系統(tǒng)的壓力；

2. 隊(duì)列長度可以做限制丹弱，事實(shí)上德撬，秒殺時(shí)，后入隊(duì)列的用戶無法秒殺到商品躲胳，這些請(qǐng)求可以直接被拋棄蜓洪，返回活動(dòng)已結(jié)束或商品已售完信息；

2.4 消息驅(qū)動(dòng)的系統(tǒng)

具體場景：用戶新上傳了一批照片坯苹， 人臉識(shí)別系統(tǒng)需要對(duì)這個(gè)用戶的所有照片進(jìn)行聚類隆檀，聚類完成后由對(duì)賬系統(tǒng)重新生成用戶的人臉?biāo)饕?加快查詢)。這三個(gè)子系統(tǒng)間由消息隊(duì)列連接起來粹湃，前一個(gè)階段的處理結(jié)果放入隊(duì)列中恐仑，后一個(gè)階段從隊(duì)列中獲取消息繼續(xù)處理。

image

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

• 避免了直接調(diào)用下一個(gè)系統(tǒng)導(dǎo)致當(dāng)前系統(tǒng)失斘裳仆；

• 每個(gè)子系統(tǒng)對(duì)于消息的處理方式可以更為靈活，可以選擇收到消息時(shí)就處理孤钦，可以選擇定時(shí)處理歧斟，也可以劃分時(shí)間段按不同處理速度處理；

三偏形、消息隊(duì)列的兩種模式

消息隊(duì)列包括兩種模式静袖，點(diǎn)對(duì)點(diǎn)模式（point to point， queue）和發(fā)布/訂閱模式（publish/subscribe俊扭，topic）队橙。

3.1 點(diǎn)對(duì)點(diǎn)模式

點(diǎn)對(duì)點(diǎn)模式下包括三個(gè)角色：

• 消息隊(duì)列

• 發(fā)送者 (生產(chǎn)者)

• 接收者（消費(fèi)者）

image

消息發(fā)送者生產(chǎn)消息發(fā)送到queue中，然后消息接收者從queue中取出并且消費(fèi)消息统扳。消息被消費(fèi)以后喘帚，queue中不再有存儲(chǔ)，所以消息接收者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息咒钟。

點(diǎn)對(duì)點(diǎn)模式特點(diǎn)：

• 每個(gè)消息只有一個(gè)接收者（Consumer）(即一旦被消費(fèi)吹由，消息就不再在消息隊(duì)列中)；

• 發(fā)送者和接收者間沒有依賴性朱嘴，發(fā)送者發(fā)送消息之后倾鲫，不管有沒有接收者在運(yùn)行粗合，都不會(huì)影響到發(fā)送者下次發(fā)送消息；

• 接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功乌昔，以便消息隊(duì)列刪除當(dāng)前接收的消息隙疚；

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

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

• 角色主題（Topic）

• 發(fā)布者(Publisher)

• 訂閱者(Subscriber)

image

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

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

• 每個(gè)消息可以有多個(gè)訂閱者磕道；

• 發(fā)布者和訂閱者之間有時(shí)間上的依賴性供屉。針對(duì)某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后溺蕉，才能消費(fèi)發(fā)布者的消息伶丐。

• 為了消費(fèi)消息，訂閱者需要提前訂閱該角色主題疯特，并保持在線運(yùn)行哗魂；

四、常用消息隊(duì)列介紹

本部分主要介紹四種常用的消息隊(duì)列（RabbitMQ/ActiveMQ/RocketMQ/Kafka）的主要特性漓雅、優(yōu)點(diǎn)录别、缺點(diǎn)。

4.1 RabbitMQ

RabbitMQ 2007年發(fā)布邻吞，是一個(gè)在AMQP(高級(jí)消息隊(duì)列協(xié)議)基礎(chǔ)上完成的组题，可復(fù)用的企業(yè)消息系統(tǒng)秸抚，是當(dāng)前最主流的消息中間件之一毁兆。

主要特性：

1. 可靠性: 提供了多種技術(shù)可以讓你在性能和可靠性之間進(jìn)行權(quán)衡。這些技術(shù)包括持久性機(jī)制椭盏、投遞確認(rèn)徘层、發(fā)布者證實(shí)和高可用性機(jī)制；

2. 靈活的路由： 消息在到達(dá)隊(duì)列前是通過交換機(jī)進(jìn)行路由的利职。RabbitMQ為典型的路由邏輯提供了多種內(nèi)置交換機(jī)類型趣效。如果你有更復(fù)雜的路由需求，可以將這些交換機(jī)組合起來使用猪贪，你甚至可以實(shí)現(xiàn)自己的交換機(jī)類型跷敬，并且當(dāng)做RabbitMQ的插件來使用；

3. 消息集群：在相同局域網(wǎng)中的多個(gè)RabbitMQ服務(wù)器可以聚合在一起热押，作為一個(gè)獨(dú)立的邏輯代理來使用西傀；

4. 隊(duì)列高可用：隊(duì)列可以在集群中的機(jī)器上進(jìn)行鏡像，以確保在硬件問題下還保證消息安全桶癣；

5. 多種協(xié)議的支持：支持多種消息隊(duì)列協(xié)議拥褂；

6. 服務(wù)器端用Erlang語言編寫，支持只要是你能想到的所有編程語言牙寞；

7. 管理界面: RabbitMQ有一個(gè)易用的用戶界面饺鹃，使得用戶可以監(jiān)控和管理消息Broker的許多方面莫秆；

8. 跟蹤機(jī)制：如果消息異常，RabbitMQ提供消息跟蹤機(jī)制悔详，使用者可以找出發(fā)生了什么镊屎；

9. 插件機(jī)制：提供了許多插件，來從多方面進(jìn)行擴(kuò)展茄螃，也可以編寫自己的插件缝驳；

使用RabbitMQ需要：

• ErLang語言包

• RabbitMQ安裝包

RabbitMQ可以運(yùn)行在Erlang語言所支持的平臺(tái)之上：

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)點(diǎn)：

1. 由于erlang語言的特性，mq 性能較好归苍，高并發(fā)用狱；

2. 健壯、穩(wěn)定霜医、易用齿拂、跨平臺(tái)、支持多種語言肴敛、文檔齊全署海；

3. 有消息確認(rèn)機(jī)制和持久化機(jī)制，可靠性高医男；

4. 高度可定制的路由砸狞；

5. 管理界面較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用镀梭；

6. 社區(qū)活躍度高刀森；

缺點(diǎn)：

1. 盡管結(jié)合erlang語言本身的并發(fā)優(yōu)勢(shì)，性能較好报账，但是不利于做二次開發(fā)和維護(hù)研底；

2. 實(shí)現(xiàn)了代理架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點(diǎn)上排隊(duì)透罢。此特性使得RabbitMQ易于使用和部署榜晦，但是使得其運(yùn)行速度較慢，因?yàn)橹醒牍?jié)點(diǎn)增加了延遲羽圃，消息封裝后也比較大乾胶；

3. 需要學(xué)習(xí)比較復(fù)雜的接口和協(xié)議，學(xué)習(xí)和維護(hù)成本較高朽寞；

4.2 ActiveMQ

ActiveMQ是由Apache出品识窿，ActiveMQ 是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)。它非衬匀冢快速喻频，支持多種語言的客戶端和協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中吨掌，并有許多高級(jí)功能半抱。

主要特性：

1. 服從 JMS 規(guī)范：JMS 規(guī)范提供了良好的標(biāo)準(zhǔn)和保證脓恕，包括：同步或異步的消息分發(fā)，一次和僅一次的消息分發(fā)窿侈，消息接收和訂閱等等炼幔。遵從 JMS 規(guī)范的好處在于，不論使用什么 JMS 實(shí)現(xiàn)提供者史简，這些基礎(chǔ)特性都是可用的乃秀；

2. 連接性：ActiveMQ 提供了廣泛的連接選項(xiàng)，支持的協(xié)議有：HTTP/S圆兵，IP 多播跺讯，SSL，STOMP殉农，TCP刀脏，UDP，XMPP等等超凳。對(duì)眾多協(xié)議的支持讓 ActiveMQ 擁有了很好的靈活性愈污。

3. 支持的協(xié)議種類多：OpenWire、STOMP轮傍、REST暂雹、XMPP、AMQP 创夜；

4. 持久化插件和安全插件：ActiveMQ 提供了多種持久化選擇杭跪。而且，ActiveMQ 的安全性也可以完全依據(jù)用戶需求進(jìn)行自定義鑒權(quán)和授權(quán)驰吓；

5. 支持的客戶端語言種類多：除了 Java 之外涧尿，還有：C/C++，.NET檬贰，Perl现斋，PHP，Python偎蘸，Ruby；

6. 代理集群：多個(gè) ActiveMQ 代理可以組成一個(gè)集群來提供服務(wù)瞬内；

7. 異常簡單的管理：ActiveMQ 是以開發(fā)者思維被設(shè)計(jì)的迷雪。所以，它并不需要專門的管理員虫蝶，因?yàn)樗峁┝撕唵斡质褂玫墓芾硖匦哉逻帧Ｓ泻芏嘀蟹椒梢员O(jiān)控 ActiveMQ 不同層面的數(shù)據(jù)，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX能真，通過處理 JMX 的告警消息赁严，通過使用命令行腳本扰柠，甚至可以通過監(jiān)控各種類型的日志。

使用ActiveMQ需要：

• Java JDK

• ActiveMQ安裝包

ActiveMQ可以運(yùn)行在Java語言所支持的平臺(tái)之上疼约。

優(yōu)點(diǎn)：

1. 跨平臺(tái)(JAVA編寫與平臺(tái)無關(guān)有卤档，ActiveMQ幾乎可以運(yùn)行在任何的JVM上)

2. 可以用JDBC：可以將數(shù)據(jù)持久化到數(shù)據(jù)庫。雖然使用JDBC會(huì)降低ActiveMQ的性能程剥，但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲(chǔ)介質(zhì)劝枣。將消息存到數(shù)據(jù)庫，看得見摸得著织鲸。而且公司有專門的DBA去對(duì)數(shù)據(jù)庫進(jìn)行調(diào)優(yōu)舔腾，主從分離；

3. 支持JMS ：支持JMS的統(tǒng)一接口;

4. 支持自動(dòng)重連搂擦；

5. 有安全機(jī)制：支持基于shiro稳诚，jaas等多種安全配置機(jī)制，可以對(duì)Queue/Topic進(jìn)行認(rèn)證和授權(quán)瀑踢。

6. 監(jiān)控完善：擁有完善的監(jiān)控扳还，包括Web Console，JMX丘损，Shell命令行普办，Jolokia的REST API；

7. 界面友善：提供的Web Console可以滿足大部分情況徘钥，還有很多第三方的組件可以使用衔蹲，如hawtio；
   缺點(diǎn)：

8. 社區(qū)活躍度不及RabbitMQ高呈础；

9. 根據(jù)其他用戶反饋舆驶，會(huì)出莫名其妙的問題，會(huì)丟失消息而钞；

10. 目前重心放到activemq6.0產(chǎn)品-apollo沙廉，對(duì)5.x的維護(hù)較少；

11. 不適合用于上千個(gè)隊(duì)列的應(yīng)用場景臼节；

4.3 RocketMQ

RocketMQ出自 阿里公司的開源產(chǎn)品撬陵，用 Java 語言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了 Kafka网缝，并做出了自己的一些改進(jìn)巨税，消息可靠性上比 Kafka 更好。RocketMQ在阿里集團(tuán)被廣泛應(yīng)用在訂單粉臊，交易草添，充值，流計(jì)算扼仲，消息推送远寸，日志流式處理抄淑，binglog分發(fā)等場景。

主要特性：

1. 是一個(gè)隊(duì)列模型的消息中間件驰后，具有高性能肆资、高可靠、高實(shí)時(shí)倡怎、分布式特點(diǎn)迅耘；

2. Producer、Consumer监署、隊(duì)列都可以分布式颤专；

3. Producer向一些隊(duì)列輪流發(fā)送消息，隊(duì)列集合稱為Topic钠乏，Consumer如果做廣播消費(fèi)栖秕，則一個(gè)consumer實(shí)例消費(fèi)這個(gè)Topic對(duì)應(yīng)的所有隊(duì)列，如果做集群消費(fèi)晓避，則多個(gè)Consumer實(shí)例平均消費(fèi)這個(gè)topic對(duì)應(yīng)的隊(duì)列集合簇捍；

4. 能夠保證嚴(yán)格的消息順序；

5. 提供豐富的消息拉取模式俏拱；

6. 高效的訂閱者水平擴(kuò)展能力暑塑；

7. 實(shí)時(shí)的消息訂閱機(jī)制；

8. 億級(jí)消息堆積能力锅必；

9. 較少的依賴事格；

使用RocketMQ需要：

• Java JDK

• 安裝git、Maven

• RocketMQ安裝包

RocketMQ可以運(yùn)行在Java語言所支持的平臺(tái)之上搞隐。

優(yōu)點(diǎn)：

1. 單機(jī)支持 1 萬以上持久化隊(duì)列

2. RocketMQ 的所有消息都是持久化的驹愚，先寫入系統(tǒng) PAGECACHE，然后刷盤劣纲，可以保證內(nèi)存與磁盤都有一份數(shù)據(jù)逢捺，
   訪問時(shí)，直接從內(nèi)存讀取癞季。

3. 模型簡單劫瞳，接口易用（JMS 的接口很多場合并不太實(shí)用）；

4. 性能非常好绷柒，可以大量堆積消息在broker中柠新；

5. 支持多種消費(fèi)，包括集群消費(fèi)辉巡、廣播消費(fèi)等。

6. 各個(gè)環(huán)節(jié)分布式擴(kuò)展設(shè)計(jì)蕊退，主從HA郊楣；

7. 開發(fā)度較活躍憔恳，版本更新很快。

缺點(diǎn)：

支持的客戶端語言不多净蚤，目前是java及c++钥组，其中c++不成熟；
RocketMQ社區(qū)關(guān)注度及成熟度也不及前兩者今瀑；
沒有web管理界面程梦，提供了一個(gè)CLI(命令行界面)管理工具帶來查詢、管理和診斷各種問題橘荠；
沒有在 mq 核心中去實(shí)現(xiàn)JMS等接口屿附；

4.4 Kafka

Apache Kafka是一個(gè)分布式消息發(fā)布訂閱系統(tǒng)。它最初由LinkedIn公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)( a distributed commit log)哥童，挺份，之后成為Apache項(xiàng)目的一部分。Kafka系統(tǒng)快速贮懈、可擴(kuò)展并且可持久化匀泊。它的分區(qū)特性，可復(fù)制和可容錯(cuò)都是其不錯(cuò)的特性朵你。

主要特性：

1. 快速持久化各聘，可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化；

2. 高吞吐抡医，在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率躲因；

3. .完全的分布式系統(tǒng)，Broker魂拦、Producer毛仪、Consumer都原生自動(dòng)支持分布式，自動(dòng)實(shí)現(xiàn)負(fù)載均衡芯勘；

4. 支持同步和異步復(fù)制兩種HA箱靴；

5. 支持?jǐn)?shù)據(jù)批量發(fā)送和拉取荷愕；

6. zero-copy：減少IO操作步驟衡怀；

7. 數(shù)據(jù)遷移、擴(kuò)容對(duì)用戶透明安疗；

8. 無需停機(jī)即可擴(kuò)展機(jī)器抛杨；

9. 其他特性：嚴(yán)格的消息順序、豐富的消息拉取模型荐类、高效訂閱者水平擴(kuò)展怖现、實(shí)時(shí)的消息訂閱、億級(jí)的消息堆積能力、定期刪除機(jī)制屈嗤；

使用Kafka需要：

• Java JDK

• Kafka安裝包

優(yōu)點(diǎn)：

1. 客戶端語言豐富潘拨，支持java、.net饶号、php铁追、ruby、python茫船、go等多種語言琅束；

2. 性能卓越，單機(jī)寫入TPS約在百萬條/秒算谈，消息大小10個(gè)字節(jié)涩禀；

3. 提供完全分布式架構(gòu), 并有replica機(jī)制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積；

4. 支持批量操作濒生；

5. 消費(fèi)者采用Pull方式獲取消息, 消息有序, 通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次;

6. 有優(yōu)秀的第三方Kafka Web管理界面Kafka-Manager埋泵；

7. 在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開源項(xiàng)目使用罪治；

缺點(diǎn)：

1. Kafka單機(jī)超過64個(gè)隊(duì)列/分區(qū)丽声，Load會(huì)發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多觉义，load越高雁社，發(fā)送消息響應(yīng)時(shí)間變長

2. 使用短輪詢方式，實(shí)時(shí)性取決于輪詢間隔時(shí)間晒骇；

3. 消費(fèi)失敗不支持重試霉撵；

4. 支持消息順序，但是一臺(tái)代理宕機(jī)后洪囤，就會(huì)產(chǎn)生消息亂序徒坡；

5. 社區(qū)更新較慢；

4.5 RabbitMQ/ActiveMQ/RocketMQ/Kafka對(duì)比

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

image

結(jié)論:

Kafka在于分布式架構(gòu)瘤缩，RabbitMQ基于AMQP協(xié)議來實(shí)現(xiàn)喇完，RocketMQ/思路來源于kafka，改成了主從結(jié)構(gòu)剥啤，在事務(wù)性可靠性方面做了優(yōu)化锦溪。廣泛來說，電商府怯、金融等對(duì)事務(wù)性要求很高的刻诊，可以考慮RabbitMQ和RocketMQ，對(duì)性能要求高的可考慮Kafka牺丙。

五则涯、參考資料：

5.1 消息隊(duì)列：

1. 大型網(wǎng)站架構(gòu)之分布式消息隊(duì)列 http://blog.csdn.net/shaobingj126/article/details/50585035

2. 消息隊(duì)列的使用場景 https://www.zhihu.com/question/34243607/answer/127666030

3. 淺談異步消息隊(duì)列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html

4. 消息隊(duì)列的兩種模式 http://blog.csdn.net/heyutao007/article/details/50131089

5.2 RabbitMQ

1. RabbitMQ主頁 https://www.rabbitmq.com/

2. RabbitMQ學(xué)習(xí)教程 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對(duì)比（18項(xiàng)差異） 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對(duì)比

1. RocketMQ，隊(duì)列選型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/

2. RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html

3. 即時(shí)通信RabbitMQ二-性能測(cè)試 http://www.reibang.com/p/d31ae9e3bfb6

4. RabbitMq、ActiveMq粟判、ZeroMq肖揣、kafka之間的比較,資料匯總 http://blog.csdn.net/linsongbin1/article/details/47781187

5. 消息隊(duì)列軟件產(chǎn)品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html

總結(jié)：

消息隊(duì)列利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺(tái)無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成浮入。目前業(yè)界有很多的MQ產(chǎn)品，例如RabbitMQ羊异、RocketMQ事秀、ActiveMQ、Kafka野舶、ZeroMQ易迹、MetaMq等，也有直接使用數(shù)據(jù)庫redis充當(dāng)消息隊(duì)列的案例平道。而這些消息隊(duì)列產(chǎn)品睹欲，各有側(cè)重，在實(shí)際選型時(shí)一屋，需要結(jié)合自身需求及MQ產(chǎn)品特征窘疮，綜合考慮。

（原文地址：https://cloud.tencent.com/community/article/129032 冀墨。 尊重原創(chuàng)闸衫，感謝作者！）