一、JMS協(xié)議和AMQP協(xié)議

關(guān)于JMS和AMQP的區(qū)別：主要是AMQP是協(xié)議，JMS是API而RabbitMQ 基于AMQP協(xié)議，erlang語言開發(fā)，是部署最廣泛的開源消息中間件,是最受歡迎的開源消息中間件之一。

二、rabbitMq的特點(diǎn)

RabbitMQ 最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。具體特點(diǎn)包括：

可靠性（Reliability）
RabbitMQ 使用一些機(jī)制來保證可靠性，如持久化、傳輸確認(rèn)、發(fā)布確認(rèn)。

靈活的路由（Flexible Routing）
在消息進(jìn)入隊(duì)列之前，通過 Exchange 來路由消息的。對(duì)于典型的路由功能，RabbitMQ 已經(jīng)提供了一些內(nèi)置的 Exchange 來實(shí)現(xiàn)。針對(duì)更復(fù)雜的路由功能，可以將多個(gè) Exchange 綁定在一起，也通過插件機(jī)制實(shí)現(xiàn)自己的 Exchange 。

消息集群（Clustering）
多個(gè) RabbitMQ 服務(wù)器可以組成一個(gè)集群，形成一個(gè)邏輯 Broker 。

高可用（Highly Available Queues）
隊(duì)列可以在集群中的機(jī)器上進(jìn)行鏡像，使得在部分節(jié)點(diǎn)出問題的情況下隊(duì)列仍然可用。

多種協(xié)議（Multi-protocol）
RabbitMQ 支持多種消息隊(duì)列協(xié)議，比如 STOMP、MQTT 等等。

多語言客戶端（Many Clients）
RabbitMQ 幾乎支持所有常用語言，比如 Java、.NET、Ruby 等等。

管理界面（Management UI）
RabbitMQ 提供了一個(gè)易用的用戶界面，使得用戶可以監(jiān)控和管理消息 Broker 的許多方面。

跟蹤機(jī)制（Tracing）
如果消息異常，RabbitMQ 提供了消息跟蹤機(jī)制，使用者可以找出發(fā)生了什么。

插件機(jī)制（Plugin System）
RabbitMQ 提供了許多插件，來從多方面進(jìn)行擴(kuò)展，也可以編寫自己的插件。

三、rabbitMQ模型及基本概念

• Broker: 接收和分發(fā)消息的應(yīng)用，RabbitMQ Server就是Message Broker。
• Virtual host: 為了讓各個(gè)用戶可以互不干擾的工作，RabbitMQ添加了虛擬主機(jī)（Virtual Hosts）的概念。其實(shí)就是一個(gè)獨(dú)立的訪問路徑，不同用戶使用不同路徑，類似于網(wǎng)絡(luò)中的namespace概念，不同的虛擬主機(jī)各自有自己的隊(duì)列、交換機(jī)，互相不會(huì)影響。
• Connection: publisher／consumer和broker之間的TCP連接。斷開連接的操作只會(huì)在client端進(jìn)行，Broker不會(huì)斷開連接，除非出現(xiàn)網(wǎng)絡(luò)故障或broker服務(wù)出現(xiàn)問題。無論生產(chǎn)者還是消費(fèi)者，都需要與RabbitMQ建立連接后才可以完成消息的生產(chǎn)和消費(fèi)。
• Channel: 如果每一次訪問RabbitMQ都建立一個(gè)Connection，在消息量大的時(shí)候建立TCP Connection的開銷將是巨大的，效率也較低。Channel是在connection內(nèi)部建立的邏輯連接，如果應(yīng)用程序支持多線程，通常每個(gè)thread創(chuàng)建單獨(dú)的channel進(jìn)行通訊，AMQP method包含了channel id幫助客戶端和message broker識(shí)別channel，所以channel之間是完全隔離的。Channel作為輕量級(jí)的Connection極大減少了操作系統(tǒng)建立TCP connection的開銷。
• Exchange: message到達(dá)broker的第一站，根據(jù)分發(fā)規(guī)則，匹配查詢表中的routing key，分發(fā)消息到queue中去。常用的類型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
• Queue: 消息最終被送到這里等待consumer取走。一個(gè)message可以被同時(shí)拷貝到多個(gè)queue中。
• Binding: exchange和queue之間的虛擬連接，binding中可以包含routing key。Binding信息被保存到exchange中的查詢表中，用于message的分發(fā)依據(jù)。

生產(chǎn)者發(fā)送消息到broker server（RabbitMQ）。在Broker內(nèi)部，用戶創(chuàng)建Exchange／Queue，通過Binding規(guī)則將兩者聯(lián)系在一起。Exchange分發(fā)消息，根據(jù)類型／binding的不同分發(fā)策略有區(qū)別。消息最后來到Queue中，等待消費(fèi)者取走。

四、Exchange Type

RabbitMQ常用的Exchange Type有三種：fanout(廣播)、direct、topic。

• fanout:把所有發(fā)送到該Exchange的消息投遞到所有與它綁定的隊(duì)列中
• direct:把消息投遞到那些bindingkey與routing key完全匹配的隊(duì)列中。 即不同的消息被不同的隊(duì)列消費(fèi)
• topic:將消息路由到binding key與routing key模式匹配的隊(duì)列中。

五、RPC

MQ本身是基于異步的消息處理，前面的示例中所有的生產(chǎn)者（P）將消息發(fā)送到RabbitMQ后不會(huì)知道消費(fèi)者（C）處理成功或者失敗（甚至連有沒有消費(fèi)者來處理這條消息都不知道）。 但實(shí)際的應(yīng)用場(chǎng)景中，我們很可能需要一些同步處理，需要同步等待服務(wù)端將我的消息處理完成后再進(jìn)行下一步處理。這相當(dāng)于RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）。在RabbitMQ中也支持RPC。

RabbitMQ中實(shí)現(xiàn)RPC的機(jī)制是：

• 客戶端發(fā)送請(qǐng)求（消息）時(shí)，在消息的屬性（MessageProperties，在AMQP協(xié)議中定義了14中properties，這些屬性會(huì)隨著消息一起發(fā)送）中設(shè)置兩個(gè)值replyTo（一個(gè)Queue名稱，用于告訴服務(wù)器處理完成后將通知我的消息發(fā)送到這個(gè)Queue中）和correlationId（此次請(qǐng)求的標(biāo)識(shí)號(hào)，服務(wù)器處理完成后需要將此屬性返還，客戶端將根據(jù)這個(gè)id了解哪條請(qǐng)求被成功執(zhí)行了或執(zhí)行失敗）
• 服務(wù)器端收到消息并處理
• 服務(wù)器端處理完消息后，將生成一條應(yīng)答消息到replyTo指定的Queue，同時(shí)帶上correlationId屬性
• 客戶端之前已訂閱replyTo指定的Queue，從中收到服務(wù)器的應(yīng)答消息后，根據(jù)其中的correlationId屬性分析哪條請(qǐng)求被執(zhí)行了，根據(jù)執(zhí)行結(jié)果進(jìn)行后續(xù)業(yè)務(wù)處理

六、基于docker安裝rabbitMq

參考
這篇文章寫得比較全

總結(jié)

以上是生活随笔為你收集整理的rabbitMq简介及docker安装的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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