MQ並不是在尋找一個消息隊列，而是解決解耦問題的方法。本質爲：解耦請求和操作； 從同步編程模型轉向異步編程模型。
解決Rabbit相關問題 編碼與模式
解耦
- 分離請求和動作 – kfc訂單和取餐
- 提供擴展性： 不用負載均衡器
- 當處理服務無法負載時，可通過添加處理服務器，而不用負載均衡，得益於RabbitMQ自動輪詢行爲
- 零成本API：跨語言
發後即忘模型
關注任務的完成，但無須實時完成。用無須應答的消息來觸發工作
匹配該模式的兩種一般類型任務：
批處理： 針對大型數據集合的工作或轉換
通知： 對發生事件的描述
用RabbitMQ實現RPC並等待響應
私有隊列和發送確認： 消息頭的reply_to字段
集羣並處理失敗
RabbitMQ高可用性的兩種方法
1. 設置Rabbit集羣
2. 擴大程序的規模以提升性能
RabbitMQ 的內建集羣 的目標：
允許消費者和生產者在Rabbit節點崩潰的情況下繼續運行。
通過添加更多節點來線性擴展消息通信吞吐量。
集羣架構
RabbitMQ始終記錄的四種類型的內部元數據：
隊列元數據 - 隊列名稱和他們的屬性
交換器元數據 - 交換器名稱、類型和屬性
綁定元數據 - 一張簡單的表格展示瞭如何將消息路由到隊列
vhost元數據 - 爲vhost內的隊列、交換器、綁定提供命名空間和安全屬性。
構建集羣式，RabbitMQ會追蹤新的元數據類型： 集羣節點位置，以及節點與已記錄的其他類型元數據的關係。
1. 集羣中的隊列：
只有隊列所有者節點知道有關隊列的所有信息。所有其他非所有者節點只知道隊列的元數據和指向該隊列存在的那個節點的指針。
節點崩潰，集羣就與之失去了聯繫。新消息也就丟失了。讓指定隊列重回集羣的唯一方式是 恢復故障節點。
默認情況下RabbitMQ不將隊列內容和狀態複製到所有節點原因：
a. 存儲空間
b. 性能： 消息發佈時消息會到每個集羣節點，都會觸發一次磁盤活動。
往Rabbit集羣添加更多的節點意味着你將擁有更多的節點來傳播隊列。 因爲所有其他節點需要將接收到的該隊列的消息傳遞給該隊列的所有者節點。
2. 分佈交換器
交換器只是名稱和隊列的綁定列表。信道按照綁定匹配的結果，將消息路由到隊列。
創建新的交換器時，RabbitMQ會將查詢表添加到集羣中的所有節點上。這樣每個節點上的每條信道都可以訪問到新的交換器了。
當消息已經在發佈信道上，但在路由完成之前節點發生故障的話，爲避免生產者一直生產消息，造成消息丟失的風險。處理方式：
a. 使用amqp事務。
b. 使用發送方確認模式來記錄連接中斷時尚未被確認的消息。
3. 是內存節點還是磁盤節點
每個RabbitMQ節點，要麼是內存節點，要麼是磁盤節點。 內存節點將所有的隊列、交換器、綁定、用戶、權限和vhost的元數據定義都存儲在內存中。而磁盤節點將元數據存儲在磁盤中。單節點系統只允許磁盤類型的節點。在集羣中，可選擇配置部分節點爲內存節點。
RabbitMQ要求集羣中至少有一個磁盤節點。但是如果只有一個節點的話，如果這個節點崩潰了，集羣仍然可以保持運行。但是在該節點恢復前你無法更改任何東西。通常會在集羣中設置兩個磁盤節點。保證只要一個可用。
如果磁盤節點故障的話，內存節點重啓後就無法找到集羣了，所以當添加內存節點時，確保告知其所有的磁盤節點（內存節點唯一存儲 到磁盤的元數據信息是集羣中磁盤節點的地址）
升級集羣節點
獨立系統中升級到最新版RabbitMQ很容易，只需解壓新版並運行即可，舊的數據會被保留。
集羣升級並不簡單，他的升級是半自動化的。如果簡單升級會抹去集羣上的所有配置和數據。
升級步驟：
1 備份當前配置
2 關閉所有生產者並等待消費者消費完隊列中的所有消息。
3 關閉節點，並解壓新版本到現有安裝目錄
4 選擇其中一個磁盤節點作爲升級節點
5 其啓動時，該節點會持久化集羣數據升級到新版本
6 啓動其他集羣磁盤節點，會獲取升級後集羣數據
7 啓動集羣內存節點。
鏡像隊列和保留消息
RabbitMQ2.6.0之後有了內建的雙話冗餘選項：鏡像隊列； 鏡像隊列的主拷貝僅存在於一個節點上，並可在其他節點擁有從隊列拷貝。主節點不可用時，最老的從節點會被選舉成新的主隊列。
聲明並使用鏡像隊列
聲明：
queue_args={"x-ha-policy": "all"}
channel.queue_declare(queue="queuename", arguments=queue_args)
上面是在所有節點都建一個從節點。建議使用all
queue_args={"x-ha-policy" : "nodes",
"x-ha-policy-params" :["rabbit@xxx"]}
這個會在指定節點上見從節點，或造成該節點掛了，就聲明不成功了。
工作原理：
信道將消息發送到鏡像隊列時，會將消息同時發送的從隊列。類似於fanout節點。
消費者取消。
對於消費但未返回確認的消息，會重新入隊。
從故障中恢復
構建彈性消息通信基礎架構的兩部分：
1. 構建RabbitMQ集羣來確保可用性和性能
2. 編寫當節點發生故障時知道如何重連到集羣的應用程序。
通過負載均衡來處理重連到集羣：
1. 可以減少應用程序處理節點故障代碼的複雜性
2. 確保在集羣中鏈接的平均分佈
將負載均衡器放置到Rabbit集羣的前端，你就可以讓它來處理節點選擇、故障服務器檢測以及負載分佈這些複雜的事情了。
使用HAProxy做負載均衡
連接丟失和故障轉移
當故障轉移到新的節點時，你無法對集羣的狀態做任何假定。不管節點故障什麼時候發生，在檢測到故障並進行重連之後的首要任務是構造交換器、隊列和綁定，以便應用程序的運作。