一.RabbitMQ 什麼語言編寫的？
我們這邊爲什麼要重點說這個能，就是因爲他的編寫語言，才讓他能在MQ這個大家庭裏脫穎而出。
rabbitmq是Erlang編程語言編寫的：
Erlang編程語言最初目的是進行大型電信交換設備的軟件開發，是一種適用於大規模並行處理環境的高可靠性編程語言。隨着多核處理器技術的日漸普及，以及互聯網、雲計算等技術的發展，該語言的應用範圍也有逐漸擴大之勢。所以RabbitMQ 天生高性能高併發
二.RabbitMQ 遵循AMQP協議
爲什麼要重點說RabbitMQ 遵循AMQP協議呢，我們來說說AMQP
在異步通訊中，消息不會立刻到達接收方，而是被存放到一個容器中，當滿足一定的條件之後，消息會被容器發送給接收方，這個容器即消息隊列，而完成這個功能需要雙方和容器以及其中的各個組件遵守統一的約定和規則，AMQP就是這樣的一種協議，消息發送與接受的雙方遵守這個協議可以實現異步通訊。這個協議約定了消息的格式和工作方式，這樣可以避免了生產者佔用太多信道，避免導致服務雪崩效應
三.RabbitMQ各個關鍵配置說明
Server(Broker):接收客戶端連接，實現AMQP協議的消息隊列和路由功能的進程；
Virtual Host：虛擬主機的概念，類似權限控制組，一個Virtual Host裏可以有多個Exchange和Queue。
Exchange:交換機，接收生產者發送的消息，並根據Routing Key將消息路由到服務器中的隊列Queue。
ExchangeType:交換機類型決定了路由消息行爲，RabbitMQ中有三種類型Exchange，分別是fanout、direct、topic；
Message Queue：消息隊列，用於存儲還未被消費者消費的消息；
Message：由Header和body組成，Header是由生產者添加的各種屬性的集合，包括Message是否被持久化、優先級是多少、由哪個Message Queue接收等；body是真正需要發送的數據內容；
BindingKey：綁定關鍵字，將一個特定的Exchange和一個特定的Queue綁定起來。
重點講一下交換機類型，這個經常會使用到：
生產者發送消息不會向傳統方式直接將消息投遞到隊列中，而是先將消息投遞到交換機中，在由交換機轉發到具體的隊列，隊列在將消息以推送或者拉取方式給消費者進行消費。 交換機的作用根據具體的路由策略分發到不同的隊列中，交換機有四種類型。
Direct exchange（直連交換機）
直連型交換機（direct exchange）是根據消息攜帶的路由鍵（routing key）將消息投遞給對應綁定鍵的隊列。直連交換機用來處理消息的單播路由（unicast routing）（儘管它也可以處理多播路由）。下邊介紹它是如何工作的：
1）將一個隊列綁定到某個交換機上時，賦予該綁定一個綁定鍵（Binding Key），假設爲R；
2）當一個攜帶着路由鍵（Routing Key）爲R的消息被髮送給直連交換機時，交換機會把它路由給綁定鍵爲R的隊列。
直連交換機的隊列通常是循環分發任務給多個消費者（我們稱之爲輪詢）。比如說有3個消費者，4個任務。分別分發每個消費者一個任務後，第4個任務又分發給了第一個消費者。綜上，我們很容易得出一個結論，在 AMQP 0-9-1 中，消息的負載均衡是發生在消費者（consumer）之間的，而不是隊列（queue）之間
Fanout exchange（扇型交換機）將消息路由給綁定到它身上的所有隊列
扇型交換機（funout exchange）將消息路由給綁定到它身上的所有隊列，而不理會綁定的路由鍵。如果 N 個隊列綁定到某個扇型交換機上，當有消息發送給此扇型交換機時，交換機會將消息的拷貝分別發送給這所有的 N 個隊列。扇型用來交換機處理消息的廣播路由（broadcast routing）。
因爲扇型交換機投遞消息的拷貝到所有綁定到它的隊列，所以他的應用案例都極其相似：
大規模多用戶在線（MMO）遊戲可以使用它來處理排行榜更新等全局事件
體育新聞網站可以用它來近乎實時地將比分更新分發給移動客戶端
分發系統使用它來廣播各種狀態和配置更新
在羣聊的時候，它被用來分發消息給參與羣聊的用戶。（AMQP 沒有內置 presence 的概念，因此 XMPP 可能會是個更好的選擇）
Topic exchange（主題交換機）隊列通過路由鍵綁定到交換機上，然後，交換機根據消息裏的路由值，將消息路由給一個或多個綁定隊列
前面提到的 direct 規則是嚴格意義上的匹配，換言之 Routing Key 必須與 Binding Key 相匹配的時候纔將消息傳送給 Queue.
而Topic 的路由規則是一種模糊匹配，可以通過通配符滿足一部分規則就可以傳送。
它的約定是：
1）binding key 中可以存在兩種特殊字符 “” 與“#”，用於做模糊匹配，其中 “” 用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
2）routing key 爲一個句點號 “.” 分隔的字符串（我們將被句點號 “. ” 分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
binding key 與 routing key 一樣也是句點號 “.” 分隔的字符串
Headers exchange（頭交換機）類似主題交換機，但是頭交換機使用多個消息屬性來代替路由鍵建立路由規則。通過判斷消息頭的值能否與指定的綁定相匹配來確立路由規則。
headers 類型的 Exchange 不依賴於 routing key 與 binding key 的匹配規則來路由消息，而是根據發送的消息內容中的 headers 屬性進行匹配。
頭交換機可以視爲直連交換機的另一種表現形式。但直連交換機的路由鍵必須是一個字符串，而頭屬性值則沒有這個約束，它們甚至可以是整數或者哈希值（字典）等。靈活性更強（但實際上我們很少用到頭交換機）。工作流程：
1）綁定一個隊列到頭交換機上時，會同時綁定多個用於匹配的頭（header）。
2）傳來的消息會攜帶header，以及會有一個 “x-match” 參數。當 “x-match” 設置爲 “any” 時，消息頭的任意一個值被匹配就可以滿足條件，而當 “x-match” 設置爲 “all” 的時候，就需要消息頭的所有值都匹配成功。
四.應答模式：
爲了確保消息不會丟失，RabbitMQ支持消息應答。消費者發送一個消息應答，告訴RabbitMQ這個消息已經接收並且處理完畢了。RabbitMQ就可以刪除它了。 如果一個消費者掛掉卻沒有發送應答，RabbitMQ會理解爲這個消息沒有處理完全，然後交給另一個消費者去重新處理。這樣，你就可以確認即使消費者偶爾掛掉也不會丟失任何消息了。 沒有任何消息超時限制；只有當消費者掛掉時，RabbitMQ纔會重新投遞。即使處理一條消息會花費很長的時間。 消息應答是默認打開的。我們通過顯示的設置autoAsk=true關閉這種機制。現即自動應答開，一旦我們完成任務，消費者會自動發送應答。通知RabbitMQ消息已被處理，可以從內存刪除。如果消費者因宕機或鏈接失敗等原因沒有發送ACK（不同於ActiveMQ，在RabbitMQ裏，消息沒有過期的概念），則RabbitMQ會將消息重新發送給其他監聽在隊列的下一個消費者。
五.公平轉發：
目前消息轉發機制是平均分配，這樣就會出現倆個消費者，奇數的任務很耗時，偶數的任何工作量很小，造成的原因就是近當消息到達隊列進行轉發消息。並不在乎有多少任務消費者並未傳遞一個應答給RabbitMQ。僅僅盲目轉發所有的奇數給一個消費者，偶數給另一個消費者。 爲了解決這樣的問題，我們可以使用basicQos方法，傳遞參數爲prefetchCount= 1。這樣告訴RabbitMQ不要在同一時間給一個消費者超過一條消息。 換句話說，只有在消費者空閒的時候會發送下一條信息。調度分發消息的方式，也就是告訴RabbitMQ每次只給消費者處理一條消息，也就是等待消費者處理完畢並自己對剛剛處理的消息進行確認之後，才發送下一條消息，防止消費者太過於忙碌，也防止它太過去清閒。 通過 設置channel.basicQos(1);