Message Broker（訊息代理）

維基百科對 Message Broker 的定義是：Message broker 是一種中介程式模塊，它把訊息從發送方的正式訊息傳遞協議轉化為接收方的正式訊息傳遞協議，

這個定義略繁瑣，下面看看 RabbitMQ 官網對 Message broker 的定義：

Message broker 接收來自發布者的訊息并將其路由到消費者，

上面兩個定義說的都是同一件事情，但是 RabbitMQ 官網的定義里缺少了“轉換”這部分，

RabbitMQ 實作了一個加 AMQP（Advanced Message Queuing Protocol）的協議，AMQP 就如果互聯網的 HTTP 協議，它更注重于如何傳輸資料，并不關心發送的資料是什么，這也就意味著需要訊息的發送者和接收者來協調訊息的格式，

為什么需要 Message broker？

看下圖，有這樣一個應用，客戶端需要與服務器進行通信，傳遞資料，最簡單的情況就是客戶端通過 HTTP 類協議直接與服務器連接，并發送資料，

目前一切都很簡單明了，

但是，如果服務器因為維護或其它原因發生了停機，或者你想對其橫向擴展，添加更多的服務器來進行回應，那么問題就來了，客戶端目前是與這臺服務器緊密的耦合在一起了，而隨著系統的增長和進化，這種緊耦合就開始讓人頭疼，

如果，我們在客戶端與服務器之間放置一個 Message broker，那么情況就不一樣了：

客戶端首先將資料發送給 Message broker，Message broker 會對資料進行檢驗，并將其發送給服務器，

但是在這種簡單的情景下，感覺沒帶來什么好處，

但是，Message broker 可以通過簡單的設定來允許多種場景，從而讓后端服務器的橫向擴展或停機維護等作業變得輕松，并且客戶端并不會感知到任何的變化，

這種解耦的架構在分布式應用中非常的常見，這意味著所有一切所唯一依賴可用的東西就是 Message broker，因為 Message broker 唯一的作業就是傳輸資料，所以沒有必要經常對其進行改動，所以它是一個相對安全可靠的組件，

對于像 RabbitMQ 這樣可以設定集群來支持高可用的 Message broker，更是這樣，

Exchange 和 Queue（訊息交換和佇列）

上文提到過 RabbitMQ 實作了 AMQP 這個協議（RabbitMQ 所支持的 AMQP 的版本是 0.9.1），這個協議的內容很多，但為了構建入門級的分布式應用，我們只需要了解以下幾點即可，

在最簡單的場景下，RabbitMQ 的架構示意圖大致如下：

· 首先某個訊息從發布者那里發往 RabbitMQ

· 這個訊息需要宣告一個 Exchange（也可以翻譯成交換機），并被發往這個 Exchange

o Exchange 有點類似“暫存區”，訊息都會發往 Exchange，用個類比來說：Exchange 就像郵箱一樣，我們寫的信件首先都要放到郵箱里才能進行發送，

· 然后，Exchange 將使用訊息內的一些資訊以及它自己的配置來決定一潭訓多條發送訊息的路由，

· 這些路由都通向一個 Queue（佇列），訊息會存盤在這個 Queue 里，等待訊息的接收者來進行使用，

· 一個訊息的接收者可以使用 Queue 中的資訊，一旦確認這個訊息被傳遞成功，那么它將從 Queue 中被洗掉，

o RabbitMQ 所提供的松耦合的特性，主要是因為 Exchange 和 Queue 的分離，

o 繼續使用郵箱的類比，Queue 就相當于是接收信件的郵箱，而根據郵件地址，郵件系統會選擇不同的郵箱來接收郵件，

而由于 RabbitMQ 處理的是訊息，而不是信件，所以它的選項會更多：RabbitMQ 一共有 4 種 Exchange：

· Direct Exchange，它是默認的 Exchange ，它會把訊息發送到一個接收者，如果注冊了多個接收者來監聽同樣的路由 Key，那么 RabbitMQ 將會向每個 Queue 輪流發送一條訊息，相當于提供了一個簡單的負載均衡

· Fanout Exchange，它把訊息的副本發送到每個系結到該 Exchange 的 Queue 上面，而這里的 Queue 沒有辦法對訊息進行過濾，如果需要過濾，則需要在訊息接收者那里實作，

· Topic Exchange，它和 Direct Exchange 類似，但不同的是：每個訊息接收者監聽特定的路由 Key，它們會收到訊息的副本，

o 例如聊天室就可以使用 Topic Exchange，每個聊天室的 ID 可以作為路由 Key，這樣就可以保證訊息只會發送給同一個聊天室的其他參與者，

· Headers Exchange，這類 Exchange 會忽略路由 Key，取而代之的是，它們會查看訊息的 Header，并由此來決定訊息應該發往哪個 Queue，Queue 可以有一個或多個 Header 用來進行匹配，這也就開啟了復雜的路由場景，例如某個 Queue 有時可以接收到某類訊息而有時則不行，

下面僅針對 Fanout Exchange 進行進一步說明：

Fanout Exchange

當訊息被發往 RabbitMQ 的時候，需要指明它需要發送到哪個 Exchange，而這個 Exchange 就可以被設定成為所謂的 Fanout Exchange，

使用 Fanout Exchange，訊息會被克隆，并被發送到所有與這個 Exchange 系結的 Queue 上，如下圖：

這里每一個 Queue 都會得到屬于自己的訊息的副本，這些訊息副本就可以被訊息的接收者所使用，

在很多大規模多人游戲的場景中，經常使用這種方式來同步玩家的資料：每個玩家都訂閱到一個 Fanout Exchange，你游戲的實體只需要將資料發送到一個地方即可，游戲中其他的玩家就會獲得更新，而你的游戲實體就不需要知道如何資料發往每一個玩家了，

安裝 RabbitMQ 和常用工具

RabbitMQ 是使用 Erlang 語言撰寫的，這也是 RabbitMQ 能夠提供如此高的可靠性的原因之一，

安裝 RabbitMQ

所以，如果想使用 RabbitMQ，就必須安裝 Erlang，

以 Windows 作業系統為例，我們可以去 Erlang 官方網站下載 Erlang 的安裝包進行安裝，而我更喜歡 chocolatey ( https://chocolatey.org/ ) 這個 Windows 作業系統的包管理工具，

1. 安裝 Chocolatey：

a. 使用管理員打開 Powershell

b. 運行 Get-ExecutionPolicy，如果回傳是 Restricted，那么運行 Set-ExecutionPolicy AllSigned 或者 Set-ExecutionPolicy Bypass -Scope Process

c. 然后執行命令：Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

回車，等一會就安裝完了，

d. 最后輸入 choco -? 命令試一下，如果出現類似以下結果，就說明安裝成功了：

2. 使用 Chocolatey 安裝 RabbitMQ：可以在 https://chocolatey.org/packages 搜索 RabbitMQ，找到 RabbitMQ 之后，按頁面提示，使用 choco install rabbitmq 命令進行安裝即可，（安裝的程序中應該會自動安裝依賴的 Erlang，如果不行，那么就搜索 Erlang，先安裝 Erlang 即可），