rabbitmq介紹
rabbitmq是乙個訊息中介軟體，是乙個很好用的訊息佇列框架，這裡有幾個關鍵的名詞：
connectionfactory、connection、channel都是rabbitmq對外提供的api中最基本的物件。connection是rabbitmq的socket鏈結，它封裝了socket協議相關部分邏輯。connectionfactory為connection的製造工廠。
channel是我們與rabbitmq打交道的最重要的乙個介面，我們大部分的業務操作是在channel這個介面中完成的，包括定義queue、定義exchange、繫結queue與exchange、發布訊息等。乙個connection可以建立多個channel也就是通道，這些通道相互不影響，就像是一條光纜和一根光纖的關係；
顧名思義，就是存放訊息的佇列，先入先出，關注佇列的消費者從佇列中取出訊息消費，如果多個消費者同時訂閱同乙個佇列，那麼訊息會平均分配到多個消費者
在實際應用中，可能會發生消費者收到queue中的訊息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致訊息丟失。為了避免這種情況發生，我們可以要求消費者在消費完訊息後傳送乙個回執給rabbitmq，rabbitmq收到訊息回執（message acknowledgment）後才將該訊息從queue中移除；如果rabbitmq沒有收到回執並檢測到消費者的rabbitmq連線斷開，則rabbitmq會將該訊息傳送給其他消費者（如果存在多個消費者）進行處理。這裡不存在timeout概念，乙個消費者處理訊息時間再長也不會導致該訊息被傳送給其他消費者，除非它的rabbitmq連線斷開。
這裡會產生另外乙個問題，如果我們的開發人員在處理完業務邏輯後，忘記傳送回執給rabbitmq，這將會導致嚴重的bug——queue中堆積的訊息會越來越多；消費者重啟後會重複消費這些訊息並重複執行業務邏輯…
如果我們希望即使在rabbitmq服務重啟的情況下，也不會丟失訊息，我們可以將queue與message都設定為可持久化的（durable），這樣可以保證絕大部分情況下我們的rabbitmq訊息不會丟失。但依然解決不了小概率丟失事件的發生（比如rabbitmq伺服器已經接收到生產者的訊息，但還沒來得及持久化該訊息時rabbitmq伺服器就斷電了），如果我們需要對這種小概率事件也要管理起來，那麼我們要用到事務。由於這裡僅為rabbitmq的簡單介紹，所以這裡將不講解rabbitmq相關的事務。
前面我們講到如果有多個消費者同時訂閱同乙個queue中的訊息，queue中的訊息會被平攤給多個消費者。這時如果每個訊息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閒的情況。我們可以通過設定prefetchcount來限制queue每次傳送給每個消費者的訊息數，比如我們設定prefetchcount=1，則queue每次給每個消費者傳送一條訊息；消費者處理完這條訊息後queue會再給該消費者傳送一條訊息。
在上一節我們看到生產者將訊息投遞到queue中，實際上這在rabbitmq中這種事情永遠都不會發生。實際的情況是，生產者將訊息傳送到exchange（交換器，下圖中的x），由exchange將訊息路由到乙個或多個queue中（或者丟棄）。
生產者在將訊息傳送給exchange的時候，一般會指定乙個routing key，來指定這個訊息的路由規則，而這個routing key需要與exchange type及binding key聯合使用才能最終生效。
在exchange type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在傳送訊息給exchange時，通過指定routing key來決定訊息流向**。
rabbitmq為routing key設定的長度限制為255 bytes。
rabbitmq中通過binding將exchange與queue關聯起來，這樣rabbitmq就知道如何正確地將訊息路由到指定的queue了。
在繫結（binding）exchange與queue的同時，一般會指定乙個binding key；消費者將訊息傳送給exchange時，一般會指定乙個routing key；當binding key與routing key相匹配時，訊息將會被路由到對應的queue中。這個將在exchange types章節會列舉實際的例子加以說明。
在繫結多個queue到同乙個exchange的時候，這些binding允許使用相同的binding key。
binding key 並不是在所有情況下都生效，它依賴於exchange type，比如fanout型別的exchange就會無視binding key，而是將訊息路由到所有繫結到該exchange的queue。
rabbitmq常用的exchange type有fanout、direct、topic、headers這四種（amqp規範裡還提到兩種exchange type，分別為system與自定義，這裡不予以描述），下面分別進行介紹。
fanout型別的exchange路由規則非常簡單，它會把所有傳送到該exchange的訊息路由到所有與它繫結的queue中。
上圖中，生產者（p）傳送到exchange（x）的所有訊息都會路由到圖中的兩個queue，並最終被兩個消費者（c1與c2）消費。
direct型別的exchange路由規則也很簡單，它會把訊息路由到那些binding key與routing key完全匹配的queue中。
以上圖的配置為例，我們以routingkey=」error」傳送訊息到exchange，則訊息會路由到queue1（amqp.gen-s9b…，這是由rabbitmq自動生成的queue名稱）和queue2（amqp.gen-agl…）；如果我們以routingkey=」info」或routingkey=」warning」來傳送訊息，則訊息只會路由到queue2。如果我們以其他routingkey傳送訊息，則訊息不會路由到這兩個queue中。
前面講到direct型別的exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic型別的exchange在匹配規則上進行了擴充套件，它與direct型別的exchage相似，也是將訊息路由到binding key與routing key相匹配的queue中，但這裡的匹配規則有些不同，它約定：
以上圖中的配置為例，routingkey=」quick.orange.rabbit」的訊息會同時路由到q1與q2，routingkey=」lazy.orange.fox」的訊息會路由到q1，routingkey=」lazy.brown.fox」的訊息會路由到q2，routingkey=」lazy.pink.rabbit」的訊息會路由到q2（只會投遞給q2一次，雖然這個routingkey與q2的兩個bindingkey都匹配）；routingkey=」quick.brown.fox」、routingkey=」orange」、routingkey=」quick.orange.male.rabbit」的訊息將會被丟棄，因為它們沒有匹配任何bindingkey。
headers型別的exchange不依賴於routing key與binding key的匹配規則來路由訊息，而是根據傳送的訊息內容中的headers屬性進行匹配。
在繫結queue與exchange時指定一組鍵值對；當訊息傳送到exchange時，rabbitmq會取到該訊息的headers（也是乙個鍵值對的形式），對比其中的鍵值對是否完全匹配queue與exchange繫結時指定的鍵值對；如果完全匹配則訊息會路由到該queue，否則不會路由到該queue。
該型別的exchange沒有用到過（不過也應該很有用武之地），所以不做介紹。
mq本身是基於非同步的訊息處理，前面的示例中所有的生產者（p）將訊息傳送到rabbitmq後不會知道消費者（c）處理成功或者失敗（甚至連有沒有消費者來處理這條訊息都不知道）。
但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的訊息處理完成後再進行下一步處理。這相當於rpc（remote procedure call，遠端過程呼叫）。在rabbitmq中也支援rpc。
rabbitmq中實現rpc的機制是：
原文出處：
RabbitMQ基本概念
總結一下傳送接收訊息的過程 www.wuxidoudizhu.com 通過上面例子對rabbitmq有乙個感性認識後，現在來介紹rabbitmq中的基本概念。broker 訊息佇列伺服器實體 訊息 每個訊息都有乙個路由鍵 routing key 的屬性。就是乙個簡單的字串。connection 應用...
RabbitMq 基本概念
rabbitmq是乙個基於amqp的訊息佇列，訊息佇列的主要目的實現訊息的生產者和消費者之間的解耦，支援多應用之間的非同步協調工作。開發語言 erlang 面向併發的程式語言。首先來一張訊息佇列的經典圖，可以劃分為三個角色 producer,queue,consumer 看到這個模型，如果對jdk的...
RabbitMQ 基本概念
amqp 核心概念 exchange 作用 是 amqp 和 rabbitmq 的核心元件 根據繫結關係和路由鍵為訊息提供路由,將訊息 至相應的佇列 有四種型別 direct topic fanout headers 使用較少 direct exchange 當 routing key 和 bind...