消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用解耦，異步消息，流量削鋒等問(wèn)題，實(shí)現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu)。目前使用較多的消息隊(duì)列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中間件到底該如何使用，何時(shí)使用這是一個(gè)問(wèn)題，胡亂地使用消息中間件增加了系統(tǒng)的復(fù)雜度，如果用不好消息中間件還不如不用。

0.消息隊(duì)列通訊模式

1)點(diǎn)對(duì)點(diǎn)通訊：點(diǎn)對(duì)點(diǎn)方式是最為傳統(tǒng)和常見(jiàn)的通訊方式，它支持一對(duì)一、一對(duì)多、多對(duì)多、多對(duì)一等多種配置方式，支持樹(shù)狀、網(wǎng)狀等多種拓?fù)浣Y(jié)構(gòu)。

2)多點(diǎn)廣播：MQ適用于不同類(lèi)型的應(yīng)用。其中重要的，也是正在發(fā)展中的是"多點(diǎn)廣播"應(yīng)用，即能夠?qū)⑾l(fā)送到多個(gè)目標(biāo)站點(diǎn)(DestinationList)?？梢允褂靡粭lMQ指令將單一消息發(fā)送到多個(gè)目標(biāo)站點(diǎn)，并確保為每一站點(diǎn)可靠地提供信息。MQ不僅提供了多點(diǎn)廣播的功能，而且還擁有智能消息分發(fā)功能，在將一條消息發(fā)送到同一系統(tǒng)上的多個(gè)用戶(hù)時(shí)，MQ將消息的一個(gè)復(fù)制版本和該系統(tǒng)上接收者的名單發(fā)送到目標(biāo)MQ系統(tǒng)。目標(biāo)MQ系統(tǒng)在本地復(fù)制這些消息，并將它們發(fā)送到名單上的隊(duì)列，從而盡可能減少網(wǎng)絡(luò)的傳輸量。

3)發(fā)布/訂閱(Publish/Subscribe)模式：發(fā)布/訂閱功能使消息的分發(fā)可以突破目的隊(duì)列地理指向的限制，使消息按照特定的主題甚至內(nèi)容進(jìn)行分發(fā)，用戶(hù)或應(yīng)用程序可以根據(jù)主題或內(nèi)容接收到所需要的消息。發(fā)布/訂閱功能使得發(fā)送者和接收者之間的耦合關(guān)系變得更為松散，發(fā)送者不必關(guān)心接收者的目的地址，而接收者也不必關(guān)心消息的發(fā)送地址，而只是根據(jù)消息的主題進(jìn)行消息的收發(fā)。在MQ家族產(chǎn)品中，MQEventBroker是專(zhuān)門(mén)用于使用發(fā)布/訂閱技術(shù)進(jìn)行數(shù)據(jù)通訊的產(chǎn)品，它支持基于隊(duì)列和直接基于TCP/IP兩種方式的發(fā)布和訂閱。

4)群集(Cluster)：為了簡(jiǎn)化點(diǎn)對(duì)點(diǎn)通訊模式中的系統(tǒng)配置，MQ提供Cluster(群集)的解決方案。群集類(lèi)似于一個(gè)域(Domain)，群集內(nèi)部的隊(duì)列管理器之間通訊時(shí)，不需要兩兩之間建立消息通道，而是采用群集(Cluster)通道與其它成員通訊，從而大大簡(jiǎn)化了系統(tǒng)配置。此外，群集中的隊(duì)列管理器之間能夠自動(dòng)進(jìn)行負(fù)載均衡，當(dāng)某一隊(duì)列管理器出現(xiàn)故障時(shí)，其它隊(duì)列管理器可以接管它的工作，從而大大提高系統(tǒng)的高可靠性。

1.使用消息隊(duì)列的理由

過(guò)去幾年中，我們一直在使用、構(gòu)建和宣傳消息隊(duì)列，我們認(rèn)為它們是很令人敬畏的，這也不是什么秘密。我們相信對(duì)任何架構(gòu)或應(yīng)用來(lái)說(shuō)，消息隊(duì)列都是一個(gè)至關(guān)重要的組件，下面是十個(gè)理由:

1. 1解耦

在項(xiàng)目啟動(dòng)之初來(lái)預(yù)測(cè)將來(lái)項(xiàng)目會(huì)碰到什么需求，是極其困難的。消息隊(duì)列在處理過(guò)程中間插入了一個(gè)隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過(guò)程都要實(shí)現(xiàn)這一接口。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過(guò)程，只要確保它們遵守同樣的接口約束。

1.2 冗余

有時(shí)在處理數(shù)據(jù)的時(shí)候處理過(guò)程會(huì)失敗。除非數(shù)據(jù)被持久化，否則將永遠(yuǎn)丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過(guò)這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。在被許多消息隊(duì)列所采用的"插入-獲取-刪除"范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要你的處理過(guò)程明確的指出該消息已經(jīng)被處理完畢，確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

1.3 擴(kuò)展性

因?yàn)橄㈥?duì)列解耦了你的處理過(guò)程，所以增大消息入隊(duì)和處理的頻率是很容易的；只要另外增加處理過(guò)程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴(kuò)展就像調(diào)大電力按鈕一樣簡(jiǎn)單。

1.4 靈活性 & 峰值處理能力

當(dāng)你的應(yīng)用上了Hacker News的首頁(yè)，你將發(fā)現(xiàn)訪(fǎng)問(wèn)流量攀升到一個(gè)不同尋常的水平。在訪(fǎng)問(wèn)量劇增的情況下，你的應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見(jiàn)；如果為以能處理這類(lèi)峰值訪(fǎng)問(wèn)為標(biāo)準(zhǔn)來(lái)投入資源隨時(shí)待命無(wú)疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住增長(zhǎng)的訪(fǎng)問(wèn)壓力，而不是因?yàn)槌鲐?fù)荷的請(qǐng)求而完全崩潰。請(qǐng)查看我們關(guān)于峰值處理能力的博客文章了解更多此方面的信息。

1.5可恢復(fù)性

當(dāng)體系的一部分組件失效，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。而這種允許重試或者延后處理請(qǐng)求的能力通常是造就一個(gè)略感不便的用戶(hù)和一個(gè)沮喪透頂?shù)挠脩?hù)之間的區(qū)別。

1.6送達(dá)保證

消息隊(duì)列提供的冗余機(jī)制保證了消息能被實(shí)際的處理，只要一個(gè)進(jìn)程讀取了該隊(duì)列即可。在此基礎(chǔ)上，IronMQ提供了一個(gè)"只送達(dá)一次"保證。無(wú)論有多少進(jìn)程在從隊(duì)列中領(lǐng)取數(shù)據(jù)，每一個(gè)消息只能被處理一次。這之所以成為可能，是因?yàn)楂@取一個(gè)消息只是"預(yù)定"了這個(gè)消息，暫時(shí)把它移出了隊(duì)列。除非客戶(hù)端明確的表示已經(jīng)處理完了這個(gè)消息，否則這個(gè)消息會(huì)被放回隊(duì)列中去，在一段可配置的時(shí)間之后可再次被處理。

1.7排序保證

在許多情況下，數(shù)據(jù)處理的順序都很重要。消息隊(duì)列本來(lái)就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來(lái)處理。IronMO保證消息漿糊通過(guò)FIFO（先進(jìn)先出）的順序來(lái)處理，因此消息在隊(duì)列中的位置就是從隊(duì)列中檢索他們的位置。

1.8緩沖

在任何重要的系統(tǒng)中，都會(huì)有需要不同的處理時(shí)間的元素。例如,加載一張圖片比應(yīng)用過(guò)濾器花費(fèi)更少的時(shí)間。消息隊(duì)列通過(guò)一個(gè)緩沖層來(lái)幫助任務(wù)最高效率的執(zhí)行--寫(xiě)入隊(duì)列的處理會(huì)盡可能的快速，而不受從隊(duì)列讀的預(yù)備處理的約束。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過(guò)系統(tǒng)的速度。

1.9 理解數(shù)據(jù)流

在一個(gè)分布式系統(tǒng)里，要得到一個(gè)關(guān)于用戶(hù)操作會(huì)用多長(zhǎng)時(shí)間及其原因的總體印象，是個(gè)巨大的挑戰(zhàn)。消息系列通過(guò)消息被處理的頻率，來(lái)方便的輔助確定那些表現(xiàn)不佳的處理過(guò)程或領(lǐng)域，這些地方的數(shù)據(jù)流都不夠優(yōu)化。

1.10 異步通信

很多時(shí)候，你不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許你把一個(gè)消息放入隊(duì)列，但并不立即處理它。你想向隊(duì)列中放入多少消息就放多少，然后在你樂(lè)意的時(shí)候再去處理它們。

?

2.消息隊(duì)列應(yīng)用場(chǎng)景

以下介紹消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場(chǎng)景。異步處理，應(yīng)用解耦，流量削鋒和消息通訊四個(gè)場(chǎng)景。

2.1異步處理

場(chǎng)景說(shuō)明：用戶(hù)注冊(cè)后，需要發(fā)注冊(cè)郵件和注冊(cè)短信。傳統(tǒng)的做法有兩種 1.串行的方式；2.并行方式
a、串行方式：將注冊(cè)信息寫(xiě)入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件，再發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)全部完成后，返回給客戶(hù)端。

b、并行方式：將注冊(cè)信息寫(xiě)入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件的同時(shí)，發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)完成后，返回給客戶(hù)端。與串行的差別是，并行的方式可以提高處理的時(shí)間

假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開(kāi)銷(xiāo)，則串行方式的時(shí)間是150毫秒，并行的時(shí)間可能是100毫秒。
因?yàn)镃PU在單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)是一定的，假設(shè)CPU1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請(qǐng)求量是7次（1000/150）。并行方式處理的請(qǐng)求量是10次（1000/100）
小結(jié)：如以上案例描述，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量，吞吐量，響應(yīng)時(shí)間）會(huì)有瓶頸。如何解決這個(gè)問(wèn)題呢？

引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯，異步處理。改造后的架構(gòu)如下：

按照以上約定，用戶(hù)的響應(yīng)時(shí)間相當(dāng)于是注冊(cè)信息寫(xiě)入數(shù)據(jù)庫(kù)的時(shí)間，也就是50毫秒。注冊(cè)郵件，發(fā)送短信寫(xiě)入消息隊(duì)列后，直接返回，因此寫(xiě)入消息隊(duì)列的速度很快，基本可以忽略，因此用戶(hù)的響應(yīng)時(shí)間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。

2.2應(yīng)用解耦

場(chǎng)景說(shuō)明：用戶(hù)下單后，訂單系統(tǒng)需要通知庫(kù)存系統(tǒng)。傳統(tǒng)的做法是，訂單系統(tǒng)調(diào)用庫(kù)存系統(tǒng)的接口。如下圖：

傳統(tǒng)模式的缺點(diǎn)：假如庫(kù)存系統(tǒng)無(wú)法訪(fǎng)問(wèn)，則訂單減庫(kù)存將失敗，從而導(dǎo)致訂單失敗，訂單系統(tǒng)與庫(kù)存系統(tǒng)耦合

如何解決以上問(wèn)題呢？引入應(yīng)用消息隊(duì)列后的方案，如下圖：

訂單系統(tǒng)：用戶(hù)下單后，訂單系統(tǒng)完成持久化處理，將消息寫(xiě)入消息隊(duì)列，返回用戶(hù)訂單下單成功
庫(kù)存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫(kù)存系統(tǒng)根據(jù)下單信息，進(jìn)行庫(kù)存操作
假如：在下單時(shí)庫(kù)存系統(tǒng)不能正常使用。也不影響正常下單，因?yàn)橄聠魏?#xff0c;訂單系統(tǒng)寫(xiě)入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫(kù)存系統(tǒng)的應(yīng)用解耦

2.3流量削鋒

流量削鋒也是消息隊(duì)列中的常用場(chǎng)景，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛。
應(yīng)用場(chǎng)景：秒殺活動(dòng)，一般會(huì)因?yàn)榱髁窟^(guò)大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個(gè)問(wèn)題，一般需要在應(yīng)用前端加入消息隊(duì)列。
a、可以控制活動(dòng)的人數(shù)
b、可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用

用戶(hù)的請(qǐng)求，服務(wù)器接收后，首先寫(xiě)入消息隊(duì)列。假如消息隊(duì)列長(zhǎng)度超過(guò)最大數(shù)量，則直接拋棄用戶(hù)請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁(yè)面。
秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請(qǐng)求信息，再做后續(xù)處理

2.4日志處理

日志處理是指將消息隊(duì)列用在日志處理中，比如Kafka的應(yīng)用，解決大量日志傳輸?shù)膯?wèn)題。架構(gòu)簡(jiǎn)化如下

日志采集客戶(hù)端，負(fù)責(zé)日志數(shù)據(jù)采集，定時(shí)寫(xiě)受寫(xiě)入Kafka隊(duì)列
Kafka消息隊(duì)列，負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)
日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)?

2.5消息通訊

消息通訊是指，消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊。比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列，或者聊天室等
點(diǎn)對(duì)點(diǎn)通訊：

客戶(hù)端A和客戶(hù)端B使用同一隊(duì)列，進(jìn)行消息通訊。

聊天室通訊：

客戶(hù)端A，客戶(hù)端B，客戶(hù)端N訂閱同一主題，進(jìn)行消息發(fā)布和接收。實(shí)現(xiàn)類(lèi)似聊天室效果。

以上實(shí)際是消息隊(duì)列的兩種消息模式，點(diǎn)對(duì)點(diǎn)或發(fā)布訂閱模式。模型為示意圖，供參考。

3.消息中間件示例

3.1電商系統(tǒng)

消息隊(duì)列采用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。
（1）應(yīng)用將主干邏輯處理完成后，寫(xiě)入消息隊(duì)列。消息發(fā)送是否成功可以開(kāi)啟消息的確認(rèn)模式。（消息隊(duì)列返回消息接收成功狀態(tài)后，應(yīng)用再返回，這樣保障消息的完整性）
（2）擴(kuò)展流程（發(fā)短信，配送處理）訂閱隊(duì)列消息。采用推或拉的方式獲取消息并處理。
（3）消息將應(yīng)用解耦的同時(shí)，帶來(lái)了數(shù)據(jù)一致性問(wèn)題，可以采用最終一致性方式解決。比如主數(shù)據(jù)寫(xiě)入數(shù)據(jù)庫(kù)，擴(kuò)展應(yīng)用根據(jù)消息隊(duì)列，并結(jié)合數(shù)據(jù)庫(kù)方式實(shí)現(xiàn)基于消息隊(duì)列的后續(xù)處理。

3.2日志收集系統(tǒng)

分為Zookeeper注冊(cè)中心，日志收集客戶(hù)端，Kafka集群和Storm集群（OtherApp）四部分組成。
Zookeeper注冊(cè)中心，提出負(fù)載均衡和地址查找服務(wù)
日志收集客戶(hù)端，用于采集應(yīng)用系統(tǒng)的日志，并將數(shù)據(jù)推送到kafka隊(duì)列
Kafka集群：接收，路由，存儲(chǔ)，轉(zhuǎn)發(fā)等消息處理
Storm集群：與OtherApp處于同一級(jí)別，采用拉的方式消費(fèi)隊(duì)列中的數(shù)據(jù)

以下是新浪kafka日志處理應(yīng)用案例：轉(zhuǎn)自（http://cloud.51cto.com/art/201507/484338.htm）

?

(1)Kafka：接收用戶(hù)日志的消息隊(duì)列

(2)Logstash：做日志解析，統(tǒng)一成JSON輸出給Elasticsearch

(3)Elasticsearch：實(shí)時(shí)日志分析服務(wù)的核心技術(shù)，一個(gè)schemaless，實(shí)時(shí)的數(shù)據(jù)存儲(chǔ)服務(wù)，通過(guò)index組織數(shù)據(jù)，兼具強(qiáng)大的搜索和統(tǒng)計(jì)功能

(4)Kibana：基于Elasticsearch的數(shù)據(jù)可視化組件，超強(qiáng)的數(shù)據(jù)可視化能力是眾多公司選擇ELK stack的重要原因

?

4.JMS消息服務(wù)

講消息隊(duì)列就不得不提JMS 。JMS（Java Message Service，Java消息服務(wù)）API是一個(gè)消息服務(wù)的標(biāo)準(zhǔn)/規(guī)范，允許應(yīng)用程序組件基于JavaEE平臺(tái)創(chuàng)建、發(fā)送、接收和讀取消息。它使分布式通信耦合度更低，消息服務(wù)更加可靠以及異步性。
在EJB架構(gòu)中，有消息bean可以無(wú)縫的與JM消息服務(wù)集成。在J2EE架構(gòu)模式中，有消息服務(wù)者模式，用于實(shí)現(xiàn)消息與應(yīng)用直接的解耦。

4.1消息模型

在JMS標(biāo)準(zhǔn)中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

4.1.1 P2P模式

P2P模式包含三個(gè)角色：消息隊(duì)列（Queue），發(fā)送者(Sender)，接收者(Receiver)。每個(gè)消息都被發(fā)送到一個(gè)特定的隊(duì)列，接收者從隊(duì)列中獲取消息。隊(duì)列保留著消息，直到他們被消費(fèi)或超時(shí)。

P2P的特點(diǎn)
每個(gè)消息只有一個(gè)消費(fèi)者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)
發(fā)送者和接收者之間在時(shí)間上沒(méi)有依賴(lài)性，也就是說(shuō)當(dāng)發(fā)送者發(fā)送了消息之后，不管接收者有沒(méi)有正在運(yùn)行，它不會(huì)影響到消息被發(fā)送到隊(duì)列
接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功
如果希望發(fā)送的每個(gè)消息都會(huì)被成功處理的話(huà)，那么需要P2P模式。

4.1.2 Pub/Sub模式

包含三個(gè)角色主題（Topic），發(fā)布者（Publisher），訂閱者（Subscriber） 多個(gè)發(fā)布者將消息發(fā)送到Topic，系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。

Pub/Sub的特點(diǎn)
每個(gè)消息可以有多個(gè)消費(fèi)者
發(fā)布者和訂閱者之間有時(shí)間上的依賴(lài)性。針對(duì)某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息
為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)
為了緩和這樣嚴(yán)格的時(shí)間相關(guān)性，JMS允許訂閱者創(chuàng)建一個(gè)可持久化的訂閱。這樣，即使訂閱者沒(méi)有被激活（運(yùn)行），它也能接收到發(fā)布者的消息。
如果希望發(fā)送的消息可以不被做任何處理、或者只被一個(gè)消息者處理、或者可以被多個(gè)消費(fèi)者處理的話(huà)，那么可以采用Pub/Sub模型。

4.2消息消費(fèi)

在JMS中，消息的產(chǎn)生和消費(fèi)都是異步的。對(duì)于消費(fèi)來(lái)說(shuō)，JMS的消息者可以通過(guò)兩種方式來(lái)消費(fèi)消息。
（1）同步
訂閱者或接收者通過(guò)receive方法來(lái)接收消息，receive方法在接收到消息之前（或超時(shí)之前）將一直阻塞；

（2）異步
訂閱者或接收者可以注冊(cè)為一個(gè)消息監(jiān)聽(tīng)器。當(dāng)消息到達(dá)之后，系統(tǒng)自動(dòng)調(diào)用監(jiān)聽(tīng)器的onMessage方法。

JNDI：Java命名和目錄接口,是一種標(biāo)準(zhǔn)的Java命名系統(tǒng)接口?？梢栽诰W(wǎng)絡(luò)上查找和訪(fǎng)問(wèn)服務(wù)。通過(guò)指定一個(gè)資源名稱(chēng)，該名稱(chēng)對(duì)應(yīng)于數(shù)據(jù)庫(kù)或命名服務(wù)中的一個(gè)記錄，同時(shí)返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪(fǎng)問(wèn)發(fā)送目標(biāo)或消息來(lái)源的作用。

5.常用消息隊(duì)列

一般商用的容器，比如WebLogic，JBoss，都支持JMS標(biāo)準(zhǔn)，開(kāi)發(fā)上很方便。但免費(fèi)的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內(nèi)容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點(diǎn)。

5.1 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力強(qiáng)勁的開(kāi)源消息總線(xiàn)。ActiveMQ 是一個(gè)完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，盡管JMS規(guī)范出臺(tái)已經(jīng)是很久的事情了，但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。

ActiveMQ特性如下：

• 多種語(yǔ)言和協(xié)議編寫(xiě)客戶(hù)端。語(yǔ)言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
• 完全支持JMS1.1和J2EE 1.4規(guī)范 （持久化，XA消息，事務(wù))
• ?對(duì)Spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性
• ?通過(guò)了常見(jiàn)J2EE服務(wù)器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測(cè)試，其中通過(guò)JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動(dòng)的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上
• ?支持多種傳送協(xié)議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
• 支持通過(guò)JDBC和journal提供高速的消息持久化
• 從設(shè)計(jì)上保證了高性能的集群，客戶(hù)端-服務(wù)器，點(diǎn)對(duì)點(diǎn)
• 支持Ajax
• 支持與Axis的整合
• 可以很容易得調(diào)用內(nèi)嵌JMS provider，進(jìn)行測(cè)試

5.2 RabbitMQ

RabbitMQ是流行的開(kāi)源消息隊(duì)列系統(tǒng)，用erlang語(yǔ)言開(kāi)發(fā)。RabbitMQ是AMQP（高級(jí)消息隊(duì)列協(xié)議）的標(biāo)準(zhǔn)實(shí)現(xiàn)。支持多種客戶(hù)端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。結(jié)構(gòu)圖如下：

幾個(gè)重要概念：

• Broker：簡(jiǎn)單來(lái)說(shuō)就是消息隊(duì)列服務(wù)器實(shí)體。
• Exchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列。
• Queue：消息隊(duì)列載體，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列。
• Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來(lái)。
• Routing Key：路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞。
• vhost：虛擬主機(jī)，一個(gè)broker里可以開(kāi)設(shè)多個(gè)vhost，用作不同用戶(hù)的權(quán)限分離。
• producer：消息生產(chǎn)者，就是投遞消息的程序。
• consumer：消息消費(fèi)者，就是接受消息的程序。
• channel：消息通道，在客戶(hù)端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話(huà)任務(wù)。

消息隊(duì)列的使用過(guò)程，如下：

• 客戶(hù)端連接到消息隊(duì)列服務(wù)器，打開(kāi)一個(gè)channel。
• 客戶(hù)端聲明一個(gè)exchange，并設(shè)置相關(guān)屬性。
• 客戶(hù)端聲明一個(gè)queue，并設(shè)置相關(guān)屬性。
• 客戶(hù)端使用routing key，在exchange和queue之間建立好綁定關(guān)系。
• 客戶(hù)端投遞消息到exchange。

exchange接收到消息后，就根據(jù)消息的key和已經(jīng)設(shè)置的binding，進(jìn)行消息路由，將消息投遞到一個(gè)或多個(gè)隊(duì)列里。

5.3 ZeroMQ

號(hào)稱(chēng)史上最快的消息隊(duì)列，它實(shí)際類(lèi)似于Socket的一系列接口，他跟Socket的區(qū)別是：普通的socket是端到端的（1:1的關(guān)系），而ZMQ卻是可以N：M 的關(guān)系，人們對(duì)BSD套接字的了解較多的是點(diǎn)對(duì)點(diǎn)的連接，點(diǎn)對(duì)點(diǎn)連接需要顯式地建立連接、銷(xiāo)毀連接、選擇協(xié)議（TCP/UDP）和處理錯(cuò)誤等，而ZMQ屏蔽了這些細(xì)節(jié)，讓你的網(wǎng)絡(luò)編程更為簡(jiǎn)單。ZMQ用于node與node間的通信，node可以是主機(jī)或者是進(jìn)程。

引用官方的說(shuō)法： “ZMQ(以下ZeroMQ簡(jiǎn)稱(chēng)ZMQ)是一個(gè)簡(jiǎn)單好用的傳輸層，像框架一樣的一個(gè)socket library，他使得Socket編程更加簡(jiǎn)單、簡(jiǎn)潔和性能更高。是一個(gè)消息處理隊(duì)列庫(kù)，可在多個(gè)線(xiàn)程、內(nèi)核和主機(jī)盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進(jìn)入Linux內(nèi)核”?，F(xiàn)在還未看到它們的成功。但是，它無(wú)疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝。ZMQ讓編寫(xiě)高性能網(wǎng)絡(luò)應(yīng)用程序極為簡(jiǎn)單和有趣。”

特點(diǎn)是：

• 高性能，非持久化

• 跨平臺(tái)：支持Linux、Windows、OS X等

• 多語(yǔ)言支持； C、C++、Java、.NET、python等30多種開(kāi)發(fā)語(yǔ)言

• 可單獨(dú)部署或集成到應(yīng)用中使用

• 可作為Socket通信庫(kù)使用

與RabbitMQ相比，ZMQ并不像是一個(gè)傳統(tǒng)意義上的消息隊(duì)列服務(wù)器，事實(shí)上，它也根本不是一個(gè)服務(wù)器，更像一個(gè)底層的網(wǎng)絡(luò)通訊庫(kù)，在Socket API之上做了一層封裝，將網(wǎng)絡(luò)通訊、進(jìn)程通訊和線(xiàn)程通訊抽象為統(tǒng)一的API接口。支持“Request-Reply “，”P(pán)ublisher-Subscriber“，”P(pán)arallel Pipeline”三種基本模型和擴(kuò)展模型。

ZeroMQ高性能設(shè)計(jì)要點(diǎn)：

1、無(wú)鎖的隊(duì)列模型

?? 對(duì)于跨線(xiàn)程間的交互（用戶(hù)端和session）之間的數(shù)據(jù)交換通道pipe，采用無(wú)鎖的隊(duì)列算法CAS；在pipe兩端注冊(cè)有異步事件，在讀或者寫(xiě)消息到pipe的時(shí)，會(huì)自動(dòng)觸發(fā)讀寫(xiě)事件。

2、批量處理的算法

?? 對(duì)于傳統(tǒng)的消息處理，每個(gè)消息在發(fā)送和接收的時(shí)候，都需要系統(tǒng)的調(diào)用，這樣對(duì)于大量的消息，系統(tǒng)的開(kāi)銷(xiāo)比較大，zeroMQ對(duì)于批量的消息，進(jìn)行了適應(yīng)性的優(yōu)化，可以批量的接收和發(fā)送消息。

3、多核下的線(xiàn)程綁定，無(wú)須CPU切換

?? 區(qū)別于傳統(tǒng)的多線(xiàn)程并發(fā)模式，信號(hào)量或者臨界區(qū)， zeroMQ充分利用多核的優(yōu)勢(shì)，每個(gè)核綁定運(yùn)行一個(gè)工作者線(xiàn)程，避免多線(xiàn)程之間的CPU切換開(kāi)銷(xiāo)。

?

5.4 Kafka

Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費(fèi)者規(guī)模的網(wǎng)站中的所有動(dòng)作流數(shù)據(jù)。 這種動(dòng)作（網(wǎng)頁(yè)瀏覽，搜索和其他用戶(hù)的行動(dòng)）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會(huì)功能的一個(gè)關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過(guò)處理日志和日志聚合來(lái)解決。 對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線(xiàn)分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka的目的是通過(guò)hadoop的并行加載機(jī)制來(lái)統(tǒng)一線(xiàn)上和離線(xiàn)的消息處理，也是為了通過(guò)集群機(jī)來(lái)提供實(shí)時(shí)的消費(fèi)。

Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，有如下特性：

• 通過(guò)O(1)的磁盤(pán)數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對(duì)于即使數(shù)以TB的消息存儲(chǔ)也能夠保持長(zhǎng)時(shí)間的穩(wěn)定性能。（文件追加的方式寫(xiě)入數(shù)據(jù)，過(guò)期的數(shù)據(jù)定期刪除）
• 高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬(wàn)的消息
• 支持通過(guò)Kafka服務(wù)器和消費(fèi)機(jī)集群來(lái)分區(qū)消息
• 支持Hadoop并行數(shù)據(jù)加載

Kafka相關(guān)概念

• Broker：Kafka集群包含一個(gè)或多個(gè)服務(wù)器，這種服務(wù)器被稱(chēng)為broker[5]
• Topic：每條發(fā)布到Kafka集群的消息都有一個(gè)類(lèi)別，這個(gè)類(lèi)別被稱(chēng)為T(mén)opic。（物理上不同Topic的消息分開(kāi)存儲(chǔ)，邏輯上一個(gè)Topic的消息雖然保存于一個(gè)或多個(gè)broker上但用戶(hù)只需指定消息的Topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）
• Partition：Parition是物理上的概念，每個(gè)Topic包含一個(gè)或多個(gè)Partition.
• Producer：負(fù)責(zé)發(fā)布消息到Kafka broker
• Consumer：消息消費(fèi)者，向Kafka broker讀取消息的客戶(hù)端。
• Consumer Group：每個(gè)Consumer屬于一個(gè)特定的Consumer Group（可為每個(gè)Consumer指定group name，若不指定group name則屬于默認(rèn)的group）。

一般應(yīng)用在大數(shù)據(jù)日志處理或?qū)?shí)時(shí)性（少量延遲），可靠性（少量丟數(shù)據(jù)）要求稍低的場(chǎng)景使用。

6.使用消息隊(duì)列需要考慮的問(wèn)題

6.1你也許并不需要消息隊(duì)列

消息隊(duì)列是一個(gè)能讓你獲得容錯(cuò)性，分布式，解耦等架構(gòu)能力的系統(tǒng)。紙上談兵的話(huà)，它看起來(lái)還不錯(cuò)。

或許消息列隊(duì)在你的應(yīng)用中有不少適用的場(chǎng)景。你可以看下這篇關(guān)于消息隊(duì)列優(yōu)點(diǎn)的文章，看看到底有哪些合適的場(chǎng)景。但可不要因?yàn)檎f(shuō)"能解耦那太好了”就輕易使用它。我們來(lái)看一個(gè)例子——你希望你的郵件發(fā)送和訂單處理互相解耦。

因此你發(fā)送一個(gè)消息到消息隊(duì)列里，然后郵件處理系統(tǒng)取出這個(gè)消息并發(fā)送郵件。那你在一個(gè)獨(dú)立的單classpath的應(yīng)用中怎么實(shí)現(xiàn)呢？讓你的訂單處理服務(wù)依賴(lài)于一個(gè)郵件服務(wù)，然后調(diào)用sendEmail()方法，而不是sendToMQ()方法。如果你使用了消息隊(duì)列，你需要定義一個(gè)兩個(gè)系統(tǒng)都能識(shí)別的消息格式 ；如果你不使用消息隊(duì)列，那么你得定義一個(gè)方法簽名。它們有什么本質(zhì)的區(qū)別嗎？其實(shí)沒(méi)有。

不過(guò)你可能還有別的消費(fèi)者想要對(duì)某個(gè)指定的消息進(jìn)行額外的處理？這的確是可能發(fā)生的，而并不只是針對(duì)我們這里說(shuō)到的這個(gè)項(xiàng)目而已。盡管確有可能，但相比添加另一個(gè)方法調(diào)用而言，它可能并不值當(dāng)。耦合？是的。不過(guò)這個(gè)耦合并沒(méi)有什么不方便的。

那我應(yīng)該如何處理峰值流量？你可以通過(guò)消息隊(duì)列將請(qǐng)求放到一個(gè)持久化隊(duì)列中，然后再一并處理它們。這是一個(gè)非常有用的特性，不過(guò)它也受限于幾個(gè) 因素——你的請(qǐng)求是在UI后臺(tái)處理，還是需要即時(shí)響應(yīng)？serlvet容器的線(xiàn)程池某種程度上可以當(dāng)作是一個(gè)隊(duì)列，用戶(hù)最終會(huì)拿到響應(yīng)，但是得需要等待（如果線(xiàn)程的超時(shí)時(shí)間過(guò)短的話(huà)，請(qǐng)求可能會(huì)丟失）。

你可以使用一個(gè)內(nèi)存隊(duì)列來(lái)存儲(chǔ)那些較重的請(qǐng)求（得在UI后臺(tái)進(jìn)行處理）。不過(guò)注意了，你的隊(duì)列并不是默認(rèn)高可用的。比如說(shuō)，如果一個(gè)消息隊(duì)列節(jié)點(diǎn)掛掉了，你的消息就丟失了。因此，不去使用應(yīng)用節(jié)點(diǎn)內(nèi)的內(nèi)存隊(duì)列，而是去使用一個(gè)消息隊(duì)列，這可能并沒(méi)有什么優(yōu)勢(shì)。

消息隊(duì)列使得我們可以進(jìn)行異步處理——這的確是個(gè)有用的特性。你不希望在用戶(hù)等待的時(shí)候做一些很重的操作。不過(guò)你也可以使用一個(gè)內(nèi)存隊(duì)列，或者簡(jiǎn)單地啟動(dòng)一個(gè)新的線(xiàn)程（比如spring的@Async注解）。這樣又有另一個(gè)問(wèn)題——如果消息丟失的話(huà)是否有問(wèn)題？如果你應(yīng)用處理請(qǐng)求的節(jié)點(diǎn)掛了，你可以進(jìn)行恢復(fù)嗎？你會(huì)發(fā)現(xiàn)這事會(huì)經(jīng)常發(fā)生，如果不保證所有消息都處理到的話(huà)，很難保證功能的正確性。因此，僅將較重的調(diào)用進(jìn)行異步處理是比較可取的。

把消息放到隊(duì)列以便讓另一個(gè)組件來(lái)進(jìn)行處理，對(duì)于這個(gè)場(chǎng)景，如果消息丟失是無(wú)法接受的 ，這也有一個(gè)很簡(jiǎn)單的解決方案——數(shù)據(jù)庫(kù)。你可以把一條processed=false的數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中。然后再運(yùn)行一個(gè)調(diào)度作業(yè)，將所有未處理的記錄挑選出來(lái)，異步地進(jìn)行處理。當(dāng)處理完成的時(shí)候，將標(biāo)記設(shè)為true。我經(jīng)常用這個(gè)方法，包括在一些大型的線(xiàn)上系統(tǒng)中，它也工作得挺好的。

這樣你還能不斷地對(duì)你的應(yīng)用節(jié)點(diǎn)進(jìn)行擴(kuò)展，只要它們的內(nèi)存中沒(méi)有任何的持久化狀態(tài)的話(huà)。不管你是否使用了消息隊(duì)列都可以（臨時(shí)的內(nèi)存處理隊(duì)列并不屬于持久化狀態(tài)）。

為什么我要給經(jīng)常用到的消息隊(duì)列提供一些備選方案？因?yàn)槿绻阌捎诓磺‘?dāng)?shù)脑蜻x擇了它，那么消息隊(duì)列可能會(huì)成為一個(gè)負(fù)擔(dān)。它們并非如想像中那樣容易使用。首先，它有一個(gè)學(xué)習(xí)曲線(xiàn)。一般來(lái)說(shuō)，你集成的組件切分得越多，就越容易出現(xiàn)問(wèn)題。其次，還有一個(gè)設(shè)置及配置的成本。比如說(shuō)，當(dāng)消息隊(duì)列需要在一個(gè)集群中運(yùn)行的話(huà)，比如說(shuō)多個(gè)數(shù)據(jù)中心，那么這就變得復(fù)雜了。

高可用性并不是上來(lái)就有的——默認(rèn)它是不會(huì)打開(kāi)的。還有就是你的應(yīng)用節(jié)點(diǎn)如何連接到消息隊(duì)列？通過(guò)一個(gè)刷新的連接池，或者使用短生命周期的DNS記錄，還是通過(guò)一個(gè)負(fù)載均衡器？你的隊(duì)列可能還有許多配置項(xiàng)，大小是多少，行為是怎樣的（消費(fèi)者需不需要確認(rèn)接受，要不要通知處理失敗，多個(gè)消費(fèi)者能夠取到同一個(gè)消息嗎，消息有沒(méi)有TTL，等等）同時(shí)還有網(wǎng)絡(luò)及消息傳遞的開(kāi)銷(xiāo)，尤其是現(xiàn)在大家都喜歡用XML或者JSON來(lái)傳輸消息。如果你過(guò)度地使用了消息隊(duì)列，那么它會(huì)增加你系統(tǒng)的延時(shí)。

最后一點(diǎn)，但并不是最次要的——如果出現(xiàn)問(wèn)題的話(huà)，使用消息隊(duì)列會(huì)讓問(wèn)題跟蹤變得異常困難。你沒(méi)法在IDE中看到所謂的調(diào)用層次，因?yàn)橐坏┠惆l(fā)送消息到隊(duì)列里了，你就得自己去查找它在哪里處理的了。這可不是聽(tīng)起來(lái)那么簡(jiǎn)單的。你看到了吧，它會(huì)給你增加許多的復(fù)雜性，以及許多需要注意的東西。

通常而言，在某些上下文中，消息隊(duì)列還是非常有用的。當(dāng)它們的確適合的話(huà)，我也會(huì)在項(xiàng)目中使用它們——比方說(shuō)，我們不想丟失消息，但又希望能快速地進(jìn)行處理。我也見(jiàn)過(guò)它在一些不太常見(jiàn)的場(chǎng)景中使用的情況，比如說(shuō)只有一個(gè)應(yīng)用節(jié)點(diǎn)來(lái)進(jìn)行消費(fèi)，不管是哪個(gè)節(jié)點(diǎn)投遞過(guò)來(lái)的消息。你還可以看下stackoverflow上的這個(gè)問(wèn)題。還有一些使用場(chǎng)景就是，或許你的確需要進(jìn)行多語(yǔ)言間的通信，又或者你的數(shù)據(jù)流已經(jīng)過(guò)于復(fù)雜了，不使用新的消息消費(fèi)者而是增加新方法調(diào)用的話(huà)代價(jià)會(huì)很大。

我想說(shuō)的是那句老掉牙的真理“殺雞焉用牛刀”。如果你不是很確定已經(jīng)沒(méi)有別的更容易管理和維護(hù)的方法，一定要使用消息隊(duì)列的話(huà)，最好不要使用它。不要因?yàn)椤比f(wàn)一它有用呢“而去用它——只有你確實(shí)覺(jué)得需要的話(huà)再去使用。因?yàn)楹苡锌赡?#xff0c;就像這里說(shuō)到的這個(gè)項(xiàng)目一樣，消息隊(duì)列其實(shí)是沒(méi)有必要的。

6.2如何避免消息丟失

選擇能夠支持消息持久化的MQ方案。如：ActiveMQ、RabbitMQ等，給消息一個(gè)處理狀態(tài)如：process=false。

還可以使用緩存方案做：如Redis，它本身也是支持持久化的。

7.本文參考資料來(lái)源

消息隊(duì)列MQ的原理及實(shí)現(xiàn)方法：http://blog.csdn.net/lzq_csdn_th/article/details/51945408

關(guān)于消息隊(duì)列的使用：http://www.cnblogs.com/linjiqin/p/5720865.html

消息隊(duì)列使用的四種場(chǎng)景介紹：http://blog.csdn.net/cws1214/article/details/52922267

使用消息隊(duì)列的十個(gè)理由：http://www.oschina.net/translate/top-10-uses-for-message-queue?p=2

國(guó)外的一款消息隊(duì)列IronMQ：http://iron.io/products/mq?rc=blog_mq_t10

你可能并不需要消息隊(duì)列：http://kb.cnblogs.com/page/212710/

轉(zhuǎn)載于:https://www.cnblogs.com/sxc1991/p/7462938.html

總結(jié)

以上是生活随笔為你收集整理的消息队列的相关知识的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。