認識RabbitMQ交換機模型

時間 2019-11-14

原文原文鏈接

前言

　

　　RabbitMQ是消息隊列中間件（Message Queue Middleware）中一種，工做雖然有用到，可是卻沒有造成很好的總體包括，主要是一些基礎概念的認識，這裏經過閱讀《RabbitMQ實戰指南》整理筆記並進行代碼實踐，更好地理解RabbitMQ！html

本文只經過講解RabbitMQ的一些基礎概念，主要是RabbitMQ的「生產者-消費者」模型涉及到的交換器、路由鍵、綁定鍵、消息路由規則等，下一篇RabbitMQ是如何運轉的？會有簡單介紹RabbitMQ的運轉、RabbitMQ部署，Java代碼實踐。java

　　須要電子書PDF版《RabbitMQ實戰指南》（高清帶標籤）能夠評論或者聯繫我服務器

1、MQ的做用

　　講解RabbitMQ以前先認識下MQ做爲消息中間件的做用（優勢），使用的時候若是不去思考爲何用MQ，怎樣更好地才能達到它的做用的話，那都是毫無心義的使用！網絡

　 一、解耦：能夠很好地屏蔽應用程序及平臺之間的特性，充當中間者，鬆散耦合應用程序及平臺，它們彼此不須要了解遠程過程調用RPC與網絡協議的細節；異步

　　二、異步通訊：能提供C/S之間同步與異步鏈接，在任什麼時候刻均可以將消息進行傳送或者存儲轉發；post

　 三、可恢復性：當消息接收方宕機或網絡不通的狀況下，消息轉儲於MQ中，直到網絡恢復或接收方恢復再進行轉發；性能

　　四、擴展性：提升消息入隊列和處理效率是容易的，只須要另外增長處理過程便可，不須要改變代碼，也不須要調節參數。url

　　五、順序性：因爲大部分MQ支持隊列模式，天然也就能保證必定的數據處理順序（事實上是不許確的，頗有侷限性。消息的順序性取決於不少因素）spa

　　六、緩衝：MQ經過一個緩衝層來幫助任務最高效率執行，寫入MQ的處理會盡量快速。3d

2、RabbitMQ的「交換機」模型

　　RabbitMQ總體的模型實際上是一種「生產者-消費者」模型，發送消息的一方稱之爲生產者，接收消息一方稱之爲消費者。中間會有交換器、隊列、Broker等概念。下圖是簡單的RabbitMQ的模型圖（截圖來自於《RabbitMQ實戰指南》，如下截圖同）

　　一、生產者-消費者與RabbitMQ Broker　

　　　　（1）Producer：

　　　　　　投遞消息的一方，建立了消息以後發佈到RabbitMQ中，消息主要包括消息體（Payload）與Label標籤，消息體能夠一般是業務數據，好比JSON等，Label則用來表述這條消息，好比一個交換機名稱和一個路由鍵。

生產者把消息交由RabbitMQ，以後會根據標籤把消息發送給感興趣的消費者。

　　　　（2 Consumer：

　　　　　　消費者，接收消息的一方，鏈接到RabbitMQ服務器，並訂閱到隊列上，當消費者消費一條消息時只是消費了消息體payload，在消息路由過程當中，消息的標籤會丟失，存入隊列中只有消息體。消費者不須要知道生產者是誰。

　　　　（3）Broker：

　　　　　　消息中間件的服務節點，一個RabbitMQ Broker能夠簡單地看作一個RabbitMQ服務節或者RabbitMQ服務實例（大多數狀況下能夠看作是一臺RabbitMQ的服務器）

　　　　由上圖可知，消息隊列運轉過程是這樣的：

　　　　封裝好的消息發送（AMQP命令爲Basic.publish）到Broker中，消費者訂閱並接收（Basic.Get/Basic.Consume）消息，以後再進行業務邏輯處理（能夠再開另外的進程，不須要與接收消息同一個進程）

　　　二、隊列

　　　　　　　RabbitMQ中消息都只能存儲在隊列中，當多個消費者訂閱一個隊列時，隊列中的消息會被平均分攤（Round-Robin），也就是並非每一個消費者都能收到全部的消息並處理。

　　　　　　注意如下幾點：

　　　　　　　　1）對於生產者生產的消息到隊列中，並非平均分攤。而是經過路由鍵、綁定鍵、交換器類型三個決定消息最終被哪一個消費者消費，以後會介紹！

　　　　　　　　2）生產者與消費者之間的鏈接，並不僅是經過隊列那麼簡單鏈接，而是外加經過TCP鏈接與信道Channel，以後也會介紹

　　　三、交換器、路由鍵、綁定　　　

　　　　　　　　（1） 交換器（Exchange, X）：由上圖交換機模型圖中看不到交換器這個東西，但其實是存在的，生產者將消息投遞到隊列，然而真實狀況是：生產者將消息發送到Exchange，由Exchange再路由到一個或多個隊列中；

　　　　　　　　　　　交換器的類型有fanout、direct、topic、headers這四種類型，不一樣的類型的交換器有其獨特的匹配規則，這裏的匹配規則其實就是決定消息最終路由到哪的隊列的關鍵，具體請往下看

　　　　　　　　（2） 路由鍵（RoutingKey）：生產者將消息發送給交換器的時候，會指定RoutingKey指定路由規則，實際狀況是須要將RoutingKey、交換器類型、綁定鍵聯合使用才能最終生效。當交換器類型與BindingKey固定狀況下，經過執行RoutingKey來決定消息流向哪裏。

　　　　　　　　（3）綁定（BindingKey）：經過綁定鍵將交換器與隊列關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到隊列，其實綁定鍵也是一種路由鍵的一種，不過是用在綁定交換器與隊列的時候。

　　　　　　總結有如下三點：

　　　　　　（1） 生產者將消息發送給哪一個Exchange是須要由RoutingKey決定的，生產者須要將Exchange與哪一個隊列綁定時須要由BindingKey決定的（固然還要看交換器類型，BindingKey不必定會生效，如fanout類型交換器）；

　　　　　（2）生產者將消息發送給交換器時，須要一個RoutingKey，當BindingKey和RoutingKey相匹配時，消息會被路由到對象的隊列中（固然也要看交換器類型）。

　　　　　（3） BindingKey其實也屬於路由鍵的一種，在使用邦定的時候，須要的路由鍵是BingdingKey，在發送消息的時，須要的路由鍵是RoutingKey

　　　四、交換器類型

　　　　　爲何非要介紹交換器類型呢？上文中也提到過交換器類型關係到具體的消息路由途徑，處路由鍵、綁定鍵以外的還須要關注交換器的類型。不一樣的交換器會有不一樣的匹配規則。

　　　　　RabbitMQ經常使用的交換器類型有fanout、direct、topic、headers這四種類型

　　　　（1）fanout：它會把全部的交換器上的消息路由到全部與該交換器邦定的隊列中，不須要BindingKey生效

　　　　（2）direct：它會把消息路由到BindingKey與RoutingKey徹底匹配的隊列中。好比在發送消息的時候，設置Label中RoutingKey爲warning，則消息會路由到Queue1與Queue2上（請看下圖）。

　　　　　（3）topic：是direct上的擴展，一樣是利用RoutingKey與BindingKey相匹配，可是匹配規則不同，支持模糊匹配。有以下的規則

- - RoutingKey爲一個點號「.」分隔的字符串，每一個被隔開的獨立字符串即爲一個單詞，是匹配的單位；
  - BindingKey和RoutingKey同樣，也是"."分割的字符串；
  - 但不一樣的是BindingKey，能夠用「#」，「*」進行相似於佔位符的模糊匹配，「#」表示一個單詞，"*"表示多個單詞（也能夠是零個）

　　　　　　　好比:

　　　　　　　　RoutingKey爲com.hidden.client的消息只會到隊列Queue2中：由於只有Queue2的BindingKey=*.*.client匹配com.hidden.client

　　　　　　　　RoutingKey爲com.rabbitmq.client的消息會到隊列Queue1-2中: 由於Queue1的BindingKey=*.rabbitmq.*.匹配com.rabbitmq.client，Queue2的BindingKey=*.*.client匹配com.rabbitmq.client

　　　　　　　　RoutingKey爲java.rabbitmq.demo的消息只會到隊列Queue1中：由於只有Queue1的BindingKey=*.rabbitmq.*.匹配java.rabbitmq.demo

　　　　　　　　RoutingKey爲java.util.concurrent的消息會被丟棄或者返回給生產者（須要設置）

　　　　　　　　（4）headers：依賴發送消息內容中的hearders屬性進行匹配，在綁定隊列和交換器時指定一組鍵值對，這裏的也就是headers，當發送消息到交換器時，RabbitMQ會獲取到該消息的headers，經過比較會路由到相關隊列中，這種交換器性能會不好，通常不會使用。

　　　　　以上內容總結起來只是介紹了RabbitMQ的從生產者產生消息到消費者消費消息過程當中涉及到的概念。還未介紹具體的RabbitMQ是如何運轉的，好比生產者是怎樣創建鏈接生成消息的，消費者又是怎樣讀取消息的，這將是下一篇RabbitMQ是如何運轉的？主要介紹的。