[TOC] # RabbitMQ整體架構 * Server：又稱為Broker。接收客戶端連接，實現AMQP的服務器實體。 * Connection：連接，應用程序與Broker的網絡連接。 * Channel：信道，幾乎所有的操作都在Channel中進行，Channel是進行消息讀寫的通道。客戶端可建立多個Channel，每個Channel代表一個會話任務。 * Message：消息。服務器和應用程序之間傳遞的數據，本質上就是一段數據，由Properties和Body組成。  --  * 左側 P 代表?產者，也就是往 RabbitMQ 發消息的程序。 * 中間即是 RabbitMQ，其中包括了交換機和隊列。 * 右側 C 代表消費者，也就是往 RabbitMQ 拿消息的程序 那么，其中?較重要的概念有 4 個，分別為：虛擬主機、交換機、隊列和綁定。 * 虛擬主機：?個虛擬主機持有?組交換機、隊列和綁定，為什么需要多個虛擬主機呢？很簡單， RabbitMQ 當中，**?戶只能在虛擬主機的粒度進?權限控制**。因此，如果需要禁? A 組訪問 B 組的交換 機/隊列/綁定，必須為 A 和 B 分別創建?個虛擬主機，每?個 RabbitMQ 服務器都有?個默認的虛擬主 機“/”。 * 交換機：Exchange ?于轉發消息，但是它不會做存儲，如果沒有 Queue bind 到 Exchange 的話，它會 直接丟棄掉 Producer 發送過來的消息。 這?有?個?較重要的概念：**路由鍵** 。消息到交換機的時候，交互機會轉發到對應的隊列中，那么究 竟轉發到哪個隊列，就要根據該路由鍵。 * 綁定：也就是交換機需要和隊列相綁定，這其中如上圖所示，是多對多的關系 # 交換機(Exchange) **特別的Exchange** 默認的Exchange（名字為空，AMQP default） 1. 默認的`Exchange`不能進行`Binding`操作 2. 任何發送到該`Exchange`的消息都會被轉發到`Routing key`指定的`Queue`中 3. 如果`vhost`中不存在`Routing key`中指定的隊列名，則該消息會被拋棄。  交換機的功能主要是接收消息并且轉發到綁定的隊列，交換機不存儲消息，在啟? ack 模式后，交換機找不 到隊列，會返回錯誤。交換機有四種類型：Direct、topic、Headers and Fanout * Direct：其類型的?為是“先匹配、再投送”，即在綁定時設定?個 **routing\_key**，消息的 **routing\_key** 匹配時，才會被交換器投送到綁定的隊列中去。 * Topic：按規則轉發消息（最靈活） * Headers：設置 header attribute 參數類型的交換機。 * Fanout：轉發消息到所有綁定隊列。 ## Direct Exchange Direct Exchange 是 RabbitMQ 默認的交換機模式，也是最簡單的模式，根據 key 全?匹配去尋找隊列。**完全匹配**  ## Topic Exchange Topic Exchange 轉發消息主要是根據通配符。在這種交換機下，隊列和交換機的綁定會定義?種路由模式， 那么，通配符就要在這種路由模式和路由鍵之間匹配后交換機才能轉發消息。 在這種交換機模式下： * 路由鍵必須是?串字符，?句號（`.`）隔開，?如 `agreements.us`，或者 `agreements.eu.stockholm`等 * 路由模式必須包含?個 星號（`* `），主要?于匹配路由鍵指定位置的?個單詞，?如，?個路由模式是 這樣?，`agreements..b.*`，那么就只能匹配路由鍵是這樣?的，第?個單詞是 agreements，第四個單 詞是 b；井號（`#`）就表示相當于?個或者多個單詞，例如?個匹配模式是 `agreements.eu.berlin.#`，那 么，以 `agreements.eu.berlin` 開頭的路由鍵都是可以的。 具體代碼發送的時候還是?樣，第?個參數表示交換機，第?個參數表示 routing key，第三個參數即消息。 如下： ~~~ rabbitTemplate.convertAndSend("testTopicExchange","key1.a.c.key2", " this is itMQ!"); ~~~ Topic 和 Direct 類似, 只是匹配上?持了“模式”，在“點分”的 routing_key 形式中, 可以使?兩個通配符: * `* `表示?個單詞； * `#`表示零個或多個詞 單詞和單詞之間需要用.隔開。 `*，# `只能寫在.號左右，且不能挨著字符  ## Headers Exchange Headers 也是根據規則匹配，相較于 Direct 和 Topic 固定地使? routing_key，headers 則是?個?定義匹配 規則的類型,根據發送的消息內容中的headers屬性進行匹配. 在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue 將消息中的`headers`與該`Exchange`相關聯的所有`Binging`中的參數進行匹配，如果匹配上了，則發送到該`Binding`對應的`Queue`中 **匹配規則** 如果`Binding`中的 `x-match = all`：表示所有的鍵值對都匹配才能轉發到消息。 `x-match = any`: 表示只要有鍵值對匹配就能轉發消息。 **注意** 1. `Binging`的時候，至少需要指定兩個參數，其中的一個是`x-match = all`或`x-match = any`。 2. `Binging`的時候，不需要指定`Routing key` 3. 發送消息的時候，不需要指定`Routing key` 4. 轉發消息的時候，忽略`Routing key` 5. 如果是`x-match = all`則發送的`headers`不能比`bingding`的參數少，否則匹配不上 ## Fanout Exchange `Fanout Exchange`這種`exchange`效率最高，`fanout > direct > topic` Fanout Exchange 消息?播的模式，不管路由鍵或者是路由模式，會把消息發給綁定給它的全部隊列，如果 配置了 `routing_key` 會被忽略. **需要注意的是，如果將消息發送到一個沒有隊列綁定的exchange上面，那么該消息將會丟失，這是因為在rabbitMQ中exchange不具備存儲消息的能力，只有隊列具備存儲消息的能力。**  # Queues屬性 * Durability：是否持久化，Durable是，Transient是否。如果不持久化，那么在服務器宕機或重啟之后Queue就會丟失。 * Auto delete：如果選擇yes，當最后一個消費者不在監聽Queue的時候，該Queue就會自動刪除，一般選擇false。 * Arguments：AMQP協議留給AMQP實現者擴展使用的。 x-message-ttl：一個消息推送到隊列中的存活時間。設置的值之后還沒消費就會被刪除。 x-expires：在自動刪除該隊列的時候，可以使用該隊列的時間。 x-max-length：在隊列頭部刪除元素之前，隊列可以包含多少個（就緒）消息，如果再次向隊列中發送消息，會刪除最早的那條消息，用來控制隊列中消息的數量。 x-max-length-bytes：在隊列頭部刪除元素之前，隊列的總消息體的大小，用來控制隊列中消息的總大小。 x-dead-letter-exchange：當消息被拒絕或者消息過期，消息重新發送到的交換機（Exchange）的可選名稱。 x-dead-letter-routing-key：當消息被拒絕或者消息過期，消息重新發送到的交換機綁定的Route key的名稱，如果沒有設置則使用之前的Route key。 x-max-priority：隊列支持的最大優先級數，如果沒有設置則不支持消息優先級 x-queue-mode：將隊列設置為延遲模式，在磁盤上保留盡可能多的消息以減少RAM使用; 如果未設置，隊列將保持在內存中的緩存，以盡可能快地傳遞消息。 x-queue-master-locator：將隊列設置為主位置模式，確定在節點集群上聲明隊列主節點所在的規則。 # Message詳解 消息。服務器和應用程序之間傳送的數據，本質上就是一段數據，由Properties和Payload(body)組成。  Delivery mode：是否持久化，如果未設置持久化，轉發到queue中并未消費則重啟服務或者服務宕機則消息丟失。 Headers：頭信息，是由一個或多個健值對組成的，當固定的Properties不滿足我們需要的時候，可以自己擴展。 **Properties（屬性）** content\_type：傳輸協議 content\_encoding：編碼方式 priority：優先級 correlation\_id：rpc屬性，請求的唯一標識。 reply\_to：rpc屬性， expiration：消息的過期時間 message\_id：消息的id timestamp：消息的時間戳 ... # 持久化 如何保證消息的不丟失，三個地方做到持久化。 1. Exchange需要持久化。 2. Queue需要持久化。 3. Message需要持久化。 # 消息流轉  把消息路由到Exchange的指定Message Queue 假設P1和C1注冊了相同的Broker，Exchange和Queue。P1發送的消息最終會被C1消費。基本的通信流程大概如下所示： 1. P1生產消息，發送給服務器端的Exchange 2. Exchange收到消息，根據ROUTINKEY，將消息轉發給匹配的Queue1 3. Queue1收到消息，將消息發送給訂閱者C1 4. C1收到消息，發送ACK給隊列確認收到消息 5. Queue1收到ACK，刪除隊列中緩存的此條消息