原文：http://blog.sina.com.cn/s/blog_790c59140102x5vk.html
一、網頁登錄方法
http://127.0.0.1:15672/
用戶名和密碼默認為guest/guest
用java代碼去連接rabbitmq用的端口是5672
二、rabbitMQ基本概念
RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
了解RabbitMQ，首先學習下AMQP。AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標准，為面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。AMQP的主要特征是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。
簡單介紹AMQP的協議棧，AMQP協議本身包含三層，如下：
Model Layer，位於協議最高層，主要定義了一些供客戶端調用的命令，客戶端可以通過這些命令實現自己的業務邏輯，例如，客戶端可以通過queue declare聲明一個隊列，利用consume命令獲取隊列的消息。
Session Layer，主要負責將客戶端命令發送給服務器，在將服務器端的應答返回給客戶端，主要為客戶端與服務器之間通信提供可靠性、同步機制和錯誤處理。
Transport Layer，主要傳輸二進制數據流，提供幀的處理、信道復用、錯誤檢測和數據表示。
這種分層架構類似於OSI網絡協議，可替換各層實現而不影響與其它層的交互。AMQP定義了合適的服務器端域模型，用於規范服務器的行為（AMQP服務器端可稱為broker）。在這里Model層決定這些基本域模型所產生的行為，這種行為在AMQP中用command表示。Session層定義客戶端與broker之間的通信（通信雙方都是一個peer，可互稱做partner），為command的可靠傳輸提供保障。Transport層專注於數據傳送，並與Session保持交互，接受上層的數據，組裝成二進制流，傳送到receiver后再解析數據，交付給Session層。Session層需要Transport層完成網絡異常情況的匯報，順序傳送command等工作。
接下來了解下AMQP當中的一些概念。
Broker（Server）：接受客戶端連接，實現AMQP消息隊列和路由功能的進程。
Virtual Host：其實是一個虛擬概念，類似於權限控制組，一個Virtual Host里面可以有若干個Exchange和Queue，但是權限控制的最小粒度是Virtual Host。
Exchange：接受生產者發送的消息，並根據Binding規則將消息路由給服務器中的隊列。ExchangeType決定了Exchange路由消息的行為，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三種，不同類型的Exchange路由的行為是不一樣的。
Message Queue：消息隊列，用於存儲還未被消費者消費的消息。
Message：由Header和Body組成，Header是由生產者添加的各種屬性的集合，包括Message是否被持久化、由哪個Message Queue接受、優先級是多少等。而Body是真正需要傳輸的APP數據。
Binding：Binding聯系了Exchange與Message Queue。Exchange在與多個Message Queue發生Binding后會生成一張路由表，路由表中存儲着Message Queue所需消息的限制條件即Binding Key。當Exchange收到Message時會解析其Header得到Routing Key，Exchange根據Routing Key與Exchange Type將Message路由到Message Queue。Binding Key由Consumer在Binding Exchange與Message Queue時指定，而Routing Key由Producer發送Message時指定，兩者的匹配方式由Exchange Type決定。
Connection：連接，對於RabbitMQ而言，其實就是一個位於客戶端和Broker之間的TCP連接。
Channel：信道，僅僅創建了客戶端到Broker之間的連接后，客戶端還是不能發送消息的。需要為每一個Connection創建Channel，AMQP協議規定只有通過Channel才能執行AMQP的命令。一個Connection可以包含多個Channel。之所以需要Channel，是因為TCP連接的建立和釋放都是十分昂貴的，如果一個客戶端每一個線程都需要與Broker交互，如果每一個線程都建立一個TCP連接，暫且不考慮TCP連接是否浪費，就算操作系統也無法承受每秒建立如此多的TCP連接。RabbitMQ建議客戶端線程之間不要共用Channel，至少要保證共用Channel的線程發送消息必須是串行的，但是建議盡量共用Connection。
Command：AMQP的命令，客戶端通過Command完成與AMQP服務器的交互來實現自身的邏輯。例如在RabbitMQ中，客戶端可以通過publish命令發送消息，txSelect開啟一個事務，txCommit提交一個事務。
消息中間件的主要功能是消息的路由(Routing)和緩存(Buffering)。在AMQP中提供類似功能的兩種域模型：Exchange 和 Message queue。
Exchange接收消息生產者(Message Producer)發送的消息根據不同的路由算法將消息發送往Message queue。Message queue會在消息不能被正常消費時緩存這些消息，具體的緩存策略由實現者決定，當message queue與消息消費者(Message consumer)之間的連接通暢時，Message queue有將消息轉發到consumer的責任。
一個Message的處理流程類似於下圖：
Message是當前模型中所操縱的基本單位，它由Producer產生，經過Broker被Consumer所消費。它的基本結構有兩部分: Header和Body。Header是由Producer添加上的各種屬性的集合，這些屬性有控制Message是否可被緩存，接收的queue是哪個，優先級是多少等。Body是真正需要傳送的數據，它是對Broker不可見的二進制數據流，在傳輸過程中不應該受到影響。
一個broker中會存在多個Message queue，Exchange怎樣知道它要把消息發送到哪個Message queue中去呢? 這就是上圖中所展示Binding的作用。Message queue的創建是由client application控制的，在創建Message queue后需要確定它來接收並保存哪個Exchange路由的結果。Binding是用來關聯Exchange與Message queue的域模型。Client application控制Exchange與某個特定Message queue關聯，並將這個queue接受哪種消息的條件綁定到Exchange，這個條件也叫Binding key或是 Criteria。
在與多個Message queue關聯后，Exchange中就會存在一個路由表，這個表中存儲着每個Message queue所需要消息的限制條件。Exchange就會檢查它接受到的每個Message的Header及Body信息，來決定將Message路由到哪個queue中去。Message的Header中應該有個屬性叫Routing Key，它由Message發送者產生，提供給Exchange路由這條Message的標准。Exchange根據不同路由算法有不同有Exchange Type。比如有Direct類似，需要Binding key等於Routing key；也有Binding key與Routing key符合一個模式關系；也有根據Message包含的某些屬性來判斷。一些基礎的路由算法由AMQP所提供，client application也可以自定義各種自己的擴展路由算法。
在AMQP中，Client application想要與Broker溝通，就需要建立起與Broker的connection，這種connection其實是與Virtual Host相關聯的，也就是說，connection是建立在client與Virtual Host之間。可以在一個connection上並發運行多個channel，每個channel執行與Broker的通信，我們前面提供的session就是依附於channel上的。
這里的Session可以有多種定義，既可以表示AMQP內部提供的command分發機制，也可以說是在宏觀上區別與域模型的接口。正常理解就是我們平時所說的交互context，主要作用就是在網絡上可靠地傳遞每一個command。在AMQP的設計中，應當是借鑒了TCP的各種設計，用於保證這種可靠性。
在Session層，為上層所需要交互的每個command分配一個惟一標識符(可以是一個UUID)，是為了在傳輸過程中可以對command做校驗和重傳。Command發送端也需要記錄每個發送出去的command到Replay Buffer，以期得到接收方的回饋，保證這個command被接收方明確地接收或是已執行這個command。對於超時沒有收到反饋的command，發送方再次重傳。如果接收方已明確地回饋信息想要告知command發送方但這條信息在中途丟失或是其它問題發送方沒有收到，那么發送方不斷重傳會對接收方產生影響，為了降低這種影響，command接收方設置一個過濾器Idempotency Barrier，來攔截那些已接收過的command。 關於這種重傳及確認機制，可以參考下TCP的相關設計。
（1）ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory為Connection的制造工廠。Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。
（2）Queue
Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。
RabbitMQ中的消息都只能存儲在Queue中，生產者（下圖中的P）生產消息並最終投遞到Queue中，消費者（下圖中的C）可以從Queue中獲取消息並消費。
多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。
（3）Message acknowledgment
在實際應用中，可能會發生消費者收到Queue中的消息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致消息丟失。為了避免這種情況發生，我們可以要求消費者在消費完消息后發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）后才將該消息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發送給其他消費者（如果存在多個消費者）進行處理。這里不存在timeout概念，一個消費者處理消息時間再長也不會導致該消息被發送給其他消費者，除非它的RabbitMQ連接斷開。這里會產生另外一個問題，如果我們的開發人員在處理完業務邏輯后，忘記發送回執給RabbitMQ，這將會導致嚴重的bug——Queue中堆積的消息會越來越多；消費者重啟后會重復消費這些消息並重復執行業務邏輯，另外pub message是沒有ack的。
（4）Message durability
如果我們希望即使在RabbitMQ服務重啟的情況下，也不會丟失消息，我們可以將Queue與Message都設置為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），如果我們需要對這種小概率事件也要管理起來，那么我們要用到事務。
（5）Prefetch count
前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時如果每個消息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閑的情況。我們可以通過設置prefetchCount來限制Queue每次發送給每個消費者的消息數，比如我們設置prefetchCount=1，則Queue每次給每個消費者發送一條消息；消費者處理完這條消息后Queue會再給該消費者發送一條消息。
（6）Exchange
在之前我們看到生產者將消息投遞到Queue中，實際上這在RabbitMQ中這種事情永遠都不會發生。實際的情況是，生產者將消息發送到Exchange（交換器，下圖中的X），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。
（7）routing key
生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。在Exchange Type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在發送消息給Exchange時，通過指定routing key來決定消息流向哪里。
RabbitMQ為routing key設定的長度限制為255 bytes。
（8）Binding
RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。
（9）Binding key
在綁定（Binding）Exchange與Queue的同時，一般會指定一個binding key；消費者將消息發送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。在綁定多個Queue到同一個Exchange的時候，這些Binding允許使用相同的binding key。binding key 並不是在所有情況下都生效，它依賴於Exchange Type，比如fanout類型的Exchange就會無視binding key，而是將消息路由到所有綁定到該Exchange的Queue。
（10）Exchange Types
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種，下面分別進行介紹。
fanout：fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。下圖中，生產者（P）發送到Exchange（X）的所有消息都會路由到圖中的兩個Queue，並最終被兩個消費者（C1與C2）消費。
direct：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中。
topic：前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這里的匹配規則有些不同，它約定：routing key為一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱為一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”；binding key與routing key一樣也是句點號“. ”分隔的字符串；binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）。
以下圖中的配置為例，routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會路由到Q1與Q2，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：headers類型的Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。
（11）RPC
MQ本身是基於異步的消息處理，前面的示例中所有的生產者（P）將消息發送到RabbitMQ后不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條消息都不知道）。但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的消息處理完成后再進行下一步處理。這相當於RPC（Remote Procedure Call，遠程過程調用）。在RabbitMQ中也支持RPC。如下圖
RabbitMQ中實現RPC的機制是：客戶端發送請求（消息）時，在消息的屬性（MessageProperties，在AMQP協議中定義了14中properties，這些屬性會隨着消息一起發送）中設置兩個值replyTo（一個Queue名稱，用於告訴服務器處理完成后將通知我的消息發送到這個Queue中）和correlationId（此次請求的標識號，服務器處理完成后需要將此屬性返還，客戶端將根據這個id了解哪條請求被成功執行了或執行失敗）。服務器端收到消息並處理。服務器端處理完消息后，將生成一條應答消息到replyTo指定的Queue，同時帶上correlationId屬性。客戶端之前已訂閱replyTo指定的Queue，從中收到服務器的應答消息后，根據其中的correlationId屬性分析哪條請求被執行了，根據執行結果進行后續業務處理
三、常用命令
創建一個用戶為mytest,密碼為mytest
rabbitmqctl add_user mytest mytest
刪除一個用戶
rabbitmqctl delete_user username
修改用戶的密碼
rabbitmqctl change_password username newpassword
查看當前用戶列表
rabbitmqctl list_users
設置用戶角色(user為用戶名, tag為角色名(對應administrator,monitoring,policymaker,management,或其他自定義名稱)
rabbitmqctl set_user_tags user tag tag tag
設置用戶權限(給用戶mytest 設置所有資源都可以讀寫權限)
rabbitmqctl set_permissions -p / mytest '.*' '.*' '.*'(配置權限的正則，寫權限的正則，讀全新的正則)
查看(指定vhostpath)所有用戶的權限信息
rabbitmqctl list_permissions -p /
查看某個指定用戶的權限信息
rabbitmqctl list_user_permissions <username>
清除某個用戶的權限信息
rabbitmqctl clear_permissions [-p vhostpath] username