僅供個人學習，如有抄襲請包容cry....

理解訊息通訊

一、       訊息通訊的概念--消費者、生產者和代理

生產者建立訊息，消費者接受這些訊息。你的應用程式可以作為生產者，向其他應用程式傳送訊息，或者作為一個消費者，接收訊息。也可以在兩者之間進行切換。不過在此之前，它必須先建立一條通道(channel)。不論你是釋出訊息、訂閱佇列或是接受訊息都是通過通道完成。

二、       AMQP元素--交換器、佇列和繫結

從概念上講，AMQP訊息路由必須有三部分：交換器、佇列和繫結。生產者把訊息釋出到交換器上；訊息最終到達佇列，並被消費者接受；繫結決定了訊息如何從路由器路由到特定的佇列。在研究交換器和繫結之前，需要先理解佇列的概念和工作原理。如下圖：

消費者通過以下兩種方式從特定佇列中接收訊息：

(1) 通過AMQP的base.consumer命令訂閱。這樣做會將通道置為接收模式，直到取消對佇列的訂閱為止。

(2) 有些時候，你只想從佇列中獲取單條訊息而不是持續訂閱。向佇列請求單條訊息是通過AMQP的base.get命令實現的。大致上講，base.get命令會訂閱訊息，獲取單條訊息，然後取消訂閱。消費者理應始終使用base.consumer來實現高吞吐量。

A: 當有多個消費者訂閱到同一個佇列上是，訊息是如何釋出的：

Q: 佇列收到的訊息將以迴圈(round-robin)的方式傳送給消費者，每條訊息只會傳送給一個消費者。訊息確認接收機制：消費者必須通過AMQP的base.ask命令顯式的向RabbitMQ傳送一個確認訊息，或者在訂閱到佇列的時候就將base.ask引數設定成true。消費者對訊息的確認和告訴生產者訊息已經被接收這兩件事毫不相關。

如何建立佇列。生產者和消費者都能使用AMQP的base.declare命令建立佇列。如果消費者在同一條通道上訂閱了另一條對列的話，就無法再宣告隊列了。則必須先取消佇列，將通道置為“傳輸”模式。

佇列設定了一些有用的引數：

1.exlusion--將引數設定成true後佇列將變為私有，限制一個佇列中只能有一個消費者。

2.auto-delete--將引數設定為true後，最後一個消費者取消訂閱之後佇列將自動移除。

聯合：交換器和繫結。

Q: 訊息是如何到達佇列的呢？

A: 路由鍵規則來指定訊息從路由器到哪個佇列。

Q: 那它是如何處理投遞到多個佇列的情況呢？

A: 協議中定義的不同型別交換器發揮了作用。一共四種類型：direct、fanout、topic和header。

direct：如果路由鍵匹配的話，訊息就被投遞到對應的佇列。

base_publish($msg,'預設交換器','佇列名稱');

fanout：當你傳送一條訊息到fanout路由器時，他會把訊息投遞給所有附加在此交換器上的佇列。可以輕而易舉地新增應用程式的功能。

base_publish($msg,'logs-exchange','error.msg-inbox');

topic：跟direct比較相像，有一些通配規則。單個“.”把路由分成幾部分，“*”匹配特定位置的任意文字，“#”匹配所有規則。

queue_bind('msg-inbox-errors','logs-exchange','error.msg-inbox');

queue_bind('msg-inbox-errors','logs-exchange','*.msg-inbox');

queue_bind('all-logs','logs-exchange','#');

三、       虛擬主機

虛擬主機vhost是AMQP概念的基礎，你必須在連線時進行指定。RabbitMQ包含了開箱即用的預設虛擬主機"/"，因此使用非常簡便。vhost之間是絕對隔離，保障了佇列和交換機的安全性，因此訊息路由的元件也無法進行互動。

rabbitmqctl add_vhost[vhost_name]

rabbitmqctl delete _vhost[vhost_name]

四、       訊息持久化

重啟rabbitmq伺服器後，那些佇列和交換器就都消失了，原因在於每個佇列和交換器的durable屬性，該屬性預設情況為false。如果需要持久化，單純將佇列和交換器的durable屬性設定為true是不夠滴。訊息釋出之前，通過把它的“投遞模式”(delivery mode)選項設定為2來把訊息標記為持久化。代價則是消耗效能，雖然重啟RabbitMQ伺服器後佇列和交換器能恢復。

五、       一條訊息經歷從生產者到消費者的生命週期

釋出者需要完成的任務：1.連線到RabbitMQ。2.獲取通道。3.宣告交換機。4.建立訊息。5.關閉訊息。6.關閉通道。7.關閉連線。

消費者需要執行的任務：1.連線到RabbitMQ。2.獲取通道。3.宣告交換機。4.宣告佇列。5.把佇列和交換機繫結起來。6.消費訊息。7.關閉通道。8.關閉連線。

使用傳送方確認模式來確認投遞。

執行和管理RabbitMQ

一、       伺服器管理—啟動和停止節點

執行子系統：rabbitmq安裝目錄下找到./sbin目錄，執行./rabbitmq-server。通過日誌檢視執行情況，日誌目錄/var/log/rabbitmq/下。以守護程式的方式在後臺執行:./rabbitmq-server detached，至此rabbitmq服務啟動成功。

當執行rabbitmq連線到控制檯時，你按下CTRL+C組合鍵後你猜是哪個..

在rabbitmq安裝目錄下執行./sbin/rabbitmqctl stop來乾淨地關閉。

rabbitmq配置檔案目錄在/etc/rabbitmq/rabbitmq.config。

二、       許可權配置

RabbitMQ許可權工作原理：使用者可以為連線到RabbitMQ主機的應用程式設計不同級別的許可權(讀、寫和“/”或配置)。

管理使用者：在RabbitMQ中，使用者是訪問控制的基本單元。針對一到多個vhost，其可以被賦予不同級別的訪問許可權，並使用標準的使用者名稱/密碼對來認證使用者。對用的增加、刪除以及列出列表，都非常簡單。這些操作都是通過rabbitmqctl完成的。

新增使用者：rabbitmqctl add_user username password

刪除使用者：rabbitmqctl delete_user username

使用者列表：rabbitmqctl list_users

設定許可權：rabbitmqctl set_permissions –p sycamore \ cashing-tier “.*” “.*” “.*”

–p sycamore：告訴set_permissions條目應該應用在哪個vhost上面。

cashing-tier：被授予許可權的使用者。

“.*” “.*” “.*”：這些是授予的許可權。這些值分別對映到配置、寫和讀。

移除許可權：rabbbimqctl clear_permissions –p sycamore cashing-tier

許可權列表：rabbitmqctl list_user_permissions cashing-tier

三、       使用統計

其中經常看到的-p選項，它指明瞭虛擬主機和路徑資訊。

rabbitmqctl list_queues -p sycamore 列出虛擬主機為sycamore的佇列列表

list_queues [-p Vhost_Path] [<QueueInfoItem>]

rabbitmqctl list_exchanges

list_exchanges  [ExchangeInfoItem]

rabbitmqctl list_bindings

理解RabbitMQ日誌，LOG_BASE=/var/log/rabbitmq

四、       RabbitMQ和Erlang問題疑難解答

由badrpc、nodedown和其他Erlang引起的問題

1. Erlang Cookie

使用rabbitmqctl命令時常出現一些莫名錯誤。先理解下rabbitmqctl的工作原理。rabbitmqctl命令先啟動Erlang節點，並從那個使用Erlang分散式系統嘗試連線RabbitMQ節點。要完成這項工作需要兩樣東西：合適的Erlang Cookie和合適的主機名稱。

Q: 那麼什麼是Erlang Cookie呢？

A: Erlang節點通過交換作為祕密令牌的Erlangcookie以獲得認證。Erlang將令牌儲存於home目錄下的.erlang.cookie檔案中

2. Erlang節點

當你啟動Erlang節點時，你可以給它兩個互斥的節點名選項，name和sname。

當你想讓rabbitmqctl能夠連上RabbitMQ時，你必須使得這些引數兩邊都能匹配([email protected])。

3. Mnesia和主機名

RabbitMQ使用Mnesia儲存佇列、交換器、繫結等資訊。RabbitMQ啟動時做的一件事就是啟動Mnesia資料庫。如果啟動Mnesia失敗，則RabbitMQ也會跟著失敗。而導致Mnesia失敗的原因大致有二：第一個也是最常見的MNESIA_BASE目錄的許可權問題。另一個常見問題是讀取表格失敗。如果主機名更改了，或是伺服器執行在叢集模式下，無法在啟動的時候連線到其他節點，都會導致啟動失敗。

4. Erlang故障排除技巧

以test作為節點名啟動Eralng節點：erl  sname  test。

執行node()函式會展示--Erlang中方括號為界的列表--你連線上的節點列表。

通過使用rpc:call，同時提供節點、模組、函式和引數作為入參，你可以在遠端rabbit上執行其他引數以獲取不同的資訊。

解決Rabbit相關問題：編碼與模式

一、       面向訊息通訊來設計應用程式

1. 非同步狀態思維(分離請求和動作)

2. 提供擴充套件性：沒有負載均衡器的世界

3. 使用AMQP來解耦應用程式最大好處：免費的API，語言不會約束訊息通訊。

二、       訊息通訊模式

解決耗時的任務和整合用不同語言編寫的應用程式。這兩個看似有不同的問題，但卻有著共同的本質：解耦請求和操作。或者換種說法，這兩個問題均需要從同步程式設計模式轉向非同步程式設計模式。

三、       發後即忘模型

匹配該模式的兩種一般型別的任務

1. 批處理(batchprocessing)--針對大型資料集合的工作和轉換。這種型別的任務可以構建為單一的任務請求，或者多個任務對資料集合的獨立部分進行操作。

2. 通知(notifications)--對發生事件的描述。內容可以是訊息的日誌，也可以是真實的報告通知給另一個程式或者是管理員。

這兩個例子符合我們之前提到的兩種類別：第一個是告警框架(傳送告警)。另一個是將單張圖片上傳並將其轉換成眾多圖片格式和尺寸(並行處理)。

四、       用RabbitMQ實現RPC

1. 私有佇列和確認傳送。

2. 使用reply_to來實現簡單的jsonRPC

叢集並處理失敗

一、       RabbitMQ叢集架構

RabbitMQ最優秀的功能之一就是其內建叢集。同時能夠將叢集在5分鐘內構建並執行起來。

RabbitMQ內建叢集的設計用於完成兩個目標：允許消費者和生產者在Rabbit節點奔潰的情況下繼續執行，以及通過新增更多的節點來線性擴充套件訊息通訊吞吐量。

Q: RabbitMQ是如何記錄你所有使用過的各種基礎構件，同時他們又如何裝配成一個訊息通訊伺服器的呢？

A: RabbitMQ會始終記錄以下四種類型的內部元資料：

1. 佇列元資料--佇列名稱和屬性(是否可持久化，是否自動刪除)

2. 交換器元資料--交換器名稱、型別和屬性(可持久化等)

3. 繫結元資料--一張簡單的表格展示瞭如何將訊息路由到佇列

4. vhost元資料--為vhost內的佇列、交換器和繫結提供名稱空間和安全屬性。

我們深入到叢集節點和他們如何儲存元資料前，首先理解在叢集環境中佇列和交換器的行為。

1. 叢集中的佇列。

2. 分佈交換器。

3. 是記憶體節點還是磁碟節點。

二、       在你的筆記本上搭建叢集

在筆記本上建立三個節點，然後將三個節點叢集，具體操作可以參考之前兩篇文章。

三、       使用物理伺服器建立叢集

分佈在不同的伺服器上建立不同的節點，將不同節點進行叢集。

四、       升級叢集節點

獨立系統中升級節點只需解壓新版本，然後執行即可，舊的資料也將會保留。如果是叢集節點，需要備份配置資訊後，關閉所有生產者等待消費者消費完佇列中的所有資訊(rabbitmqctl觀察佇列狀態)。現在，關閉節點，並解壓新版本到RabbitMQ到現有的安裝目錄。

五、       與映象佇列一起工作

當加入映象佇列後，通道負責將訊息路由到合適的佇列。

映象佇列是如何影響事務和傳送方確認模式的？

1. 映象佇列主拷貝故障時，從拷貝變成主拷貝。

2. 如果映象佇列失去一個從節點的話，則附加在映象佇列的任何消費者都不會注意到這一點。

3. 如果客戶端庫不能支援消費者取消通知的話，你應該避免使用映象佇列。

從故障中恢復

一、       理解負載均衡

負載均衡將伺服器叢集IP封裝，提供暴露成統一介面。通過將負載均衡器放置在Rabbit的前端，你就可以讓它來處理節點選擇、故障伺服器檢測以及負載分佈這些複雜的事情了。

二、       安裝並配置HAProxy來為Rabbit做負載均衡

選擇使用HAProxy的原因：它是免費的，而且非常可靠，並且為各種站點處理高負載，例如：StackOverFlow。同時，它可以執行在幾乎所有的基於UNIX的平臺上，並且非常容易配置。

1. 安裝HAProxy

2. 配置HAProxy

以上兩步自己度娘。

三、       重連並從故障中恢復

現在開發系統上執行著負載均衡器，我們準備深入探索如何使用它來為訊息通訊應用程式植入故障轉移和快速恢復的能力。

1. 如果我重新連線到新的伺服器，那麼我的通道以及其上的所有消費迴圈會怎樣呢？它們現在都失效了。你必須對它們進行重建。

2. 當我進行重連的時候，我能否假設所有的交換器、佇列和繫結仍然存在於叢集之中？我能否重連之後立即開始從佇列消費呢？

Warren和Shovel：故障轉移和複製

一、       理解主/備方式(warren)

叢集迫使你不得不在以下兩者之間做權衡：所有節點表現得像獨立單元來分佈負載的優點，但是在故障節點恢復前無法使用可持久化佇列的缺點。這正是warren和Shovel的用武之地。

二、       使用負載均衡器建立warren

基於warren的負載均衡器的HAProxy配置。基於負載均衡器來做故障轉移，最重要的是可以確保當故障轉移發生時，你無須擔心RabbitMQ無法在備用節點啟動，因為它已經運行了。由於Rabbit始終在主節點和備用節點上執行，因此你們可以始終對它們進行監控。如果備機在派上用場之前就變為不可用的話，你在第一時間就能發現。這通過使用共享儲存warren是無法做到的。

三、       使用Shovel構建遠距離複製

在掌握了叢集和warren之後，你就能處理故障並在資料中心之上進行擴充套件了，但是當你需要在不同的資料中心的Rabbit間複製訊息時，改怎麼辦呢？這時，我們就需要Shovel了。

1. 給Rabbit裝備Shovel：Shovel外掛介紹。

2. 安裝Shovel

3. 配置並執行Shovel

從Web端管理RabbitMQ

一、       Managent外掛相對於rabbitmqctl指令碼的優勢

方便、簡潔、功能齊全、瀏覽多方面同時監測。

二、       啟用RabbitMQ Management外掛

rabbitmq-plugins  enable  rabbitmq-management

三、       Management外掛功能

四、       從Web控制檯來管理使用者、佇列和交換器

在web控制檯上做如下操作：(具體結合介面應用)

1. 建立使用者

2. 管理使用者的許可權

3. 列出佇列資訊

4. 建立佇列

五、       Management外掛REST介面介紹

1. 通過使用REST API，你可以輕鬆自動化那些到目前為止只能通過圖形化介面完成的任務。

2. CLI管理：一種更簡潔的方式。

3. 安裝rabbitmqadmin指令碼。

4. 應用rabbitmqadmin指令碼。

使用REST API控制Rabbit

一、       Rabbit REST API的限制和功能

不管用API建立佇列還是設定許可權，每當使用PUT或POST動作的時候，都需要將函式引數編碼為JSON格式的雜湊表，然後新增到請求正文中。你可以通過瀏覽器訪問http://localhost:55672/api來檢視目前大多數(以及完整的)API列表和支援的HTTP動作。

二、       訪問訊息通訊資料統計和計數器

Rabbit Management API使得你可以在任何能夠訪問網路的地方監控並控制Rabbit。具體詳情看此書，程式碼來控制的。

三、       自動化建立使用者和虛擬主機

我們在部署應用時，就使用了相似的指令碼來自動化建立使用者。通過構造這段指令碼，你不僅學習瞭如何使用Management API來展示條目，還學習瞭如何展示條目列表，以及如何建立和刪除這些條目。你這樣將這些概念應用到處理其他條目/資源型別(使用者、佇列、交換器、連線、許可權等)。具體指令碼看此書。

監控

一、       編寫Nagios健康檢測的基礎

Nagios健康檢測是一個獨立程式，它在執行時監控服務並在程式停止執行時退出程式碼來指示服務的健康狀態。從技術上來講，你甚至不需要Nagios來執行健康檢測--你可以在任何時候通過命令列執行並手工觀測輸出。Nagios健康檢測可以用任何語言編寫，可以是Python程式，甚至是BASE指令碼。

二、       使用AMQP和REST API來監控Rabbit內部狀態

構建的AMQP健康檢測，當下列任務條件之一為真時，該檢測程式會返回一個critical狀態

1. RabbitMQ沒有響應TCP連線。

2. 當傳送AMQP命令時，Pika在接收到響應之前超時了。

3. 當構造AMQP通道時，遇到了協議錯誤。

僅當這些狀態檢測都為false時，健康檢測程式才會返回OK狀態。

基於API的健康檢測，aliveness-test，顧名思義，使用三個步驟來驗證Rabbit伺服器是否健康：

1. 建立一個佇列來接收測試訊息。

2. 用佇列名稱作為訊息路由鍵，將訊息發往預設交換器。

3. 當訊息到達佇列的時候就消費該訊息；否則就報錯。

三、       使用Rabbit可用並且能夠進行響應

有許多原因會致使RabbitMQ使用太多的記憶體，並達到Rabbit配置的最大記憶體上限。以下是最常見的幾種原因：

1. 應用程式有缺陷，消費訊息之後忘記向RabbitMQ發回確認訊息。這在高容量環境下，會導致成千上萬條的訊息堆積並耗盡Rabbit的記憶體。

2. 應用程式使用RabbitMQ將大型資料(譬如影象)路由到處理節點。用不了多少張100MB大小的影象就可以將只有8GB記憶體大小的伺服器記憶體耗盡。

3. 使用了最新RabbitMQ版本中的新功能，但是該功能有個BUG會導致緩慢的記憶體洩漏。

四、       觀察佇列狀態以儘早檢測消費者問題

監控消費者是否正確運作的方式就是通過監控佇列的訊息總數，並在總數超過設定的warning或者critical閾值時觸發警告。以下通過兩種方式來監控佇列訊息總數：

1. 使用AMQP的queue_declare()命令，設定passive=true引數來重新宣告一個已存在的佇列。當你在AMQP中宣告一個佇列時，如果將passive設定為true的話，那麼該命令返回的結果中將包含佇列訊息的總數。

2. 利用我們的老朋友RabbitManagement API來總佇列上拉取資料統計，其中就有隊列當前的訊息總數。

五、       檢測訊息通訊結構中不合需求的配置更改

確保消費者正常工作，檢查訊息通訊結構配置問題：

1. 通過AMQP監控佇列等級。

2. 使用REST API來監控佇列級別。

3. 建立佇列的訊息計數基準經驗法則。

提升效能，保障安全

一、       交換器、佇列和繫結的記憶體佔用

根據資料顯示佇列、交換器和繫結的記憶體佔用很小，另一個施加在RabbitMQ上的硬性限制是每個Erlang節點的最大Erlang程序數。Erlang應用程式在整個生命週期中會多次建立並銷燬程序。

二、       訊息持久化和磁碟I/O

當釋出訊息時，你需要決定丟失其中的任何訊息對你來說是否可以接受，這決定了deleverymode設定的值為1(非持久化)還是2(持久化)的問題。

在訊息消費過程中你該如何配置，加快訊息投遞的設定是no-ack標記，你可以在佇列訂閱時指明。

路由演算法和繫結規則，三種不同型別的交換器：direct、fanout和topic。每種交換器型別代表了伺服器實現的特定路由演算法。繫結規則的路由鍵模式將更佔用記憶體。

本節介紹了不同的演算法和訊息釋出訂閱設定如何影響整個系統的速度，以及像auto-ack模式標記設定能在很大程度上影響系統性能。

三、       RabbitMQ的SSL連線及設定私鑰架構

1. SSL證書。

2. 設定證書頒發機構。

3. 生成根證書。

4. 生成伺服器端證書。

5. 生成客戶端證書。

6. 啟用RabbitMQ的SSL監聽。

7. 測試你的RabbitMQ SSL設定。

聰明的Rabbit：擴充套件RabbitMQ

一、       安裝RabbitMQ外掛

我可以通過安裝外掛的方式來解決：

1. 支援AMQP以外的協議。

2. 不同的認證機制(LDQP，自定義資料庫)。

3. 訊息複製。

4. 新的交換器和路由演算法。

5. 訊息日誌和審計。

如果你想啟用的外掛不是伺服器發行的一部分該怎麼辦呢？首先，你得下載外掛的.ez檔案到RabbitMQ安裝目錄的plugins資料夾下，之後像往常一樣執行./rabbitmq-plugins enable plugin_name命令即可。

二、       實現自定義交換器外掛

1. 將交換器註冊到Rabbit。

2. 實現交換器behaviour。

3. 編譯自定義交換器。

4. 測試你的外掛。