rabbitmq 學習與實踐分享（3）

一.前言

以前rabbitmq學習與實踐分享（2）中主要談到了rabbitmq提供的一些手段和機制來從生產端，消費端以及broker端保證消息機制的可靠性。可是沒有考慮到單點故障以及broker如何抗住高負載，來保證消息中間件的高可用性。本文主要結合本身的理解談論這個問題。

rabbitmq 提供高可用性的機制主要有如下2種手段：

• 集羣
• 鏡像隊列

二.rabbitmq 集羣：

rabbitmq 的集羣有如下幾個特色:

• rabbitmq 集羣的全部節點都會備份元數據信息，可是不會備份消息。備份的元數據信息包括：
  • 1)隊列的元數據：好比隊列的名稱，屬性；
  • 2)交換器：好比交換器的名稱，屬性；
  • 3)綁定關係的元數據：交換器之間的綁定關係，以及交換器與隊列之間的綁定關係;
  • 4. vhost 的元數據；

rabbitmq 集羣中建立隊列，只會在單個節點，而不是全部節點上建立隊列的進程幷包含隊列的完整消息（元數據，狀態，內容）。建立隊列進程的節點稱爲宿主節點，該節點知道隊列的全部信息，其餘的節點僅僅知道隊列的元數據信息以及包含指向這個宿主節點的指針。 因此若是這個宿主節點因某種緣由出現宕機時，該節點中的消息會丟失。固然後面介紹的鏡像隊列能夠解決這種狀況出現的消息丟失問題。

rabbitmq 集羣的搭建：

rabbitmq集羣的搭建過程偏運維，此處就不作介紹了，涉及到相關的命令以下：

具體命令的用法以及相關含義，後面章節再單獨介紹。

rabbitmq集羣節點的類型：

• 內存節點：將全部隊列，交換器，綁定關係，vhost的用戶，權限等等元數據信息都存儲在內存裏。
• 磁盤節點: 指上述元數據信息存儲在磁盤裏。 爲了確保節點重啓以後，元數據信息不會丟失，單節點的集羣節點只能是磁盤節點，多節點的集羣中必須有一個節點是磁盤節點。

  

  如圖：上面disc 表示是磁盤節點;ram 表示是內存節點; 若是有新的隊列，或者交換器建立的時候，須要先通知磁盤節點進行保存，若是一個集羣中只有一個磁盤節點，而且不幸宕機了，那麼該集羣只能收發消息，不能進行任何新的變動操做（好比建立新的隊列）了。

鏡像隊列

鏡像隊列的機制主要做用就是經過冗餘隊列中的消息，來避免集羣中宿主隊列宕機時致使的消息丟失問題。引入鏡像隊列機制，經過將隊列鏡像到其餘的broker節點上，對一個宿主隊列（master）配置多個slave節點，從而提高可用性。

針對鏡像隊列而言：全部的操做（除了消息發送）都是先應用到隊列的主節點，而後經過主節點傳播到鏡像隊列的從節點的，當主節點宕機時，最老的從節點會自動晉升成爲新的主節點.

鏡像隊列的配置是經過policy 設置的:
  rabbitmqctl set_policy -p vhost [ --priority priority ] [--apply-to apply-to] name pattern {definition} 
複製代碼

參數簡要介紹：pattern 指要匹配的隊列模式 definition 包含3個部分:

• ha-mode :指定鏡像隊列的模式，有如下幾個取值:all 表示在全部的節點上進行鏡像;exactly 表示在指定數量的節點上進行鏡像，具體幾個節點經過ha-params參數指定;nodes 指定節點名稱列表。
• ha-params:指定不一樣的ha-params 用到的參數;
• ha-sync-mode:鏡像同步模式，分爲automatic（自動）和手動(manual). 手動的操做能夠經過rabbitmqctl sync_queue 命令完成。

小結

本文主要簡要的介紹了一下rabbitmq 如何提高可用性來保證消息不丟失的。可是在實際生產環境，面對突發的流量的時候，rabbitmq 如何能扛住呢，有沒有什麼機制能夠實現呢，好比流控? 這塊內容在下一小節繼續分享。