一、定義

    MQ（Message Queue，訊息佇列）是基於應用程式之間的一種通訊方式，應用程式通過讀寫出入佇列的訊息進行通訊，而不需要用專用的連線來連線它們。訊息通訊指的是程式之間在訊息中傳遞資訊進行通訊，而不是傳統的通過直接呼叫（如RPC）的方式進行通訊。MQ的使用除去了訊息接收和傳送的應用程式同時執行的要求。RabbitMQ是實現了AMQP協議MQ的一箇中間件，它由ERLANG語言編寫。常用的MQ中介軟體還有IBM MQ，Rocket MQ，Active MQ,Rocket MQ以及輕量級的由Redis實現的MQ。程序之間常用的通訊方式有：管道、有名管道、訊號量、訊號、共享記憶體、套接字。

二、應用場景

    對於大型的軟體系統來說，它會有很多的模組或者說是子系統，比如我在的國內某網際網路銀行，銀行的軟體架構體系中就包含了多個系統。這個時候多個系統之間的通訊就成了一個問題。傳統的IPC（程序間通訊）很多都是在單一的系統上，模組之間具有高度的耦合性，不適合做擴充套件。而使用socket進行通訊的話，雖然可以部署在多個伺服器上，但是仍然存在許多問題需要解決。諸如： 1.資訊的傳送者與接收者之間如何維持雙方之間的連線，如果連線發生中斷，傳送中的資料如何處理？ 2.如何降低雙方系統之間的耦合度？ 3.如何能夠按照優先順序處理資料？ 4.怎樣有效的處理接收者的負載？ 5.如何使用Filter有效的處理訊息到不同的接收者端？ 6.如何做到可擴充套件，有效的將訊息傳送到叢集上？ 7.如何保證訊息的可靠性？即接收者能夠接收到準確完整的訊息。     AMQP協議解決了以上問題，而RabbitMQ實現了AMQP協議

三、應用架構

    RabbitMq Server：也叫broker server ，是基於訊息傳送與接收雙方的一種傳輸服務。他的任務就是維護一條從訊息生產者到訊息接收者之間的路線，並保證訊息能夠在其中穩定準確的進行傳輸。但是這個保證並不能100%保證，不過對於中小型應用系統已經足夠了。當然如果對於大型的商業系統，則可以再封裝一層資料一致性的guard，就可以徹底保證資料的一致性了。     CilentA&ClientB：也叫Producer，訊息的傳送方，生產者。生產者傳送的訊息有兩個部分：payload和label。payload就是要傳遞的訊息內容，label是exchange的名字或者說是一個tag，RabbitMq 正是通過這個label決定把這個訊息傳送給哪個接收者。AMQP僅僅描述了label的規則，而RabbitMq決定如何使用這個規則。     Client1&Client2：也叫Consumer，訊息的接收方，消費者。訊息從生產者傳送到消費者的時候，label已經被刪掉了，也就是說消費者實際上並不知道這個訊息是從哪個生產者發來的，除非是payload訊息載體中記錄了生產者的資訊。     Exchange：交換機，收發訊息的地方，一般情況下訊息是直接從生產者傳送到隊列當中，但是有的時候我們並不知道訊息應該傳送到哪個佇列，這個時候我們就把訊息傳送到交換機，由交換機根據路由規則決定應該傳送到哪個佇列中。     Queue：佇列，儲存訊息的地方，消費者從佇列中獲取訊息。     RoutingKey：路由關鍵字，決定Exchange到Queue的規則，exchange與queue通過繫結（binding）而實現訊息傳遞。     Virtual Hosts：虛擬主機，每一個Virtual Host都相當於一個獨立的RabbitMq Server，擁有自己的exchange、queue等，彼此相互獨立。這保證了多個應用使用同一個伺服器上的RabbitMq Server。     Connection：連線，Producer和Consumer通過一條TCP連線建立與RabbitMq Server之間的連線。也就是說，訊息在傳遞之前，第一步就是建立這個TCP連線。     Channel：頻道，基於TCP連線的通道，資料的傳遞都是在Channel上進行的。也就是說當程式建立完TCP連線之後，接下來就是建立Channel通道。     之所以不直接使用TCP連線傳遞訊息而是使用通道，是因為TCP連線的開啟與關閉的代價太大，並且TCP有連線數的限制，限制了系統處理高併發的能力，後邊我們會說到，當消費者開啟多執行緒模式時，實際是開啟了多個通道，而不是多個TCP連線。

四、Exchange的型別    

    這裡著重說明一下Exchange，因為我在學習跟使用的過程中發現，exchange真的非常的重要，可以說是RabbtiMq中的一個小的核心了。     從上邊的圖中我們可以看到，傳送方將訊息傳送到Exchange中，接著通過繫結的“Routing Key”決定訊息應該傳送到哪個Queue中。這裡有四種Exchange介紹，每種實現綁定了不同的路由規則，即不同的“Routing Key”型別。     四種Exchange的型別分別為：fanout、direct、topic、header     Fanout Exchange：此種類型的Exchange不需要繫結任何的路由規則，即訊息會發送給所有與其繫結的Queue，如圖我們定義了fanout型別的交換機X，那麼由生產者P傳送到交換機X的訊息會發送給佇列queue1跟佇列queue2兩個佇列          Direct Exchange：此種類型的交換機會匹配繫結的路由規則決定訊息由交換機發送給哪個佇列。生產者傳送給交換機的訊息攜帶繫結的規則，交換機根據規則匹配佇列的繫結規則決定訊息傳送給哪個佇列。如圖，我們定義了direct型別的交換機X，交換機X與佇列queue1的繫結規則為error和warning，與佇列queue2的繫結規則為error、info和warning，那麼當生產者傳送的訊息攜帶繫結規則引數info時，交換機X只會將該訊息傳送到佇列queue2上，當傳遞的規則引數為error、warning時，交換機X會將該訊息傳送到佇列queue1與佇列queue2兩個佇列          Topic Exchange：此種類型的交換機實際上與direct型別的相似，不同的是它會對繫結規則進行模糊匹配，匹配模式有兩種，一種是‘#’匹配一個或多個單詞，另一種是‘*’匹配一個單詞。如圖，我們定義了topic型別的交換機，繫結佇列queue1的規則為#，繫結佇列queue2的規則為c.*，繫結佇列queue3的規則為*.c，那麼不管生產者傳送繫結什麼規則引數的訊息，都會被佇列queue1收到，當訊息的繫結規則引數為c.x，x為任意一個單詞時，佇列queue2會收到該訊息，為x.c時，x為任意單詞時，佇列queue3會收到該訊息          Header Exchange: 此種類型的交換機與direct型別的相似，不同的是不在使用Routing Key進行匹配，而是使用header進行匹配，header是佇列繫結時的一個引數。因為沒有看到太多使用此種類型的例子，所以此處不過多闡明。

五、環境搭建

     RabbitMq 是由erlang語言開發的，所以需要安裝erlang語言的OTP支援軟體，可以在官網上下載，也可以在我的百度雲進行下載。     安裝完OTP之後，安裝RabbitMq Server，同樣可以在官網下載，也可以在我的百度雲進行下載，     兩個軟體的安裝過程都是下一步，需要注意的是兩個軟體安裝完成之後都需要配置環境變數，安裝完成之後進入RabbitMq Server安裝目錄下的sbin目錄，開啟CMD視窗執行命令：rabbitmq-plugins enable rabbitmq_management 以啟動監聽服務。啟動成功之後在瀏覽器中輸入http：localhost:15672 出現如下視窗即表示安裝成功。          初始使用者名稱密碼均為guest     以上就是RabbitMq的一些基礎內容，還在學習當中，如果有錯誤的地方請諒解並歡迎指正。     本文參考文章：     http://blog.csdn.net/anzhsoft/article/details/19563091