rabbitmq之相關概念.md
阿新 • • 發佈:2018-12-11
RabbitMQ版本
- 版本宣告: 3.6.15
RabbitMQ相關概念
RabbitMQ
是一個Erlang
開發的AMQP(Advanced Message Queuing Protocol,高階訊息佇列協議)
的開源實現,它最初起源於金融系統- 特點
- 可靠性:
RabbitMQ
使用如持久化、傳輸確認、釋出確認等機制來保證可靠性 - 擴充套件性:多個
RabbitMQ
節點可以組成一個叢集,可以動態擴充套件叢集中的節點 - 高可用性:佇列可以在叢集中的機器上設定映象,即使部分節點出現問題佇列仍然可用
- 多種協議:
AMQP協議
、STOMP
、MOTT
等多種訊息中介軟體協議 - 多語言客戶端:
java
、Python
Ruby
、PHP
、C#
、JavaScript
、Go
、Object-C
等 - 管理介面:檢視、監控、管理訊息、叢集中節點狀態的使用者介面
- 第三方外掛豐富
- 可靠性:
AMQP
規範不僅定義了一種網路協議,同時也定義了服務端的服務與行為——AMQP模型
,AMQP模型
在邏輯上定義了三種抽象元件用於指定訊息的路由行為Exchange(交換器)
:用於把訊息路由到佇列的元件Queue(佇列)
:用於儲存訊息的資料結構(記憶體或者硬碟)Binding(繫結規則)
:一套規則,用於告訴Exchange(交換器)
訊息應該被儲存到哪個Queue(佇列)
- 模型圖
Queue
Queue(佇列)
是RabbitMQ
的內部物件,用於儲存訊息。RabbitMQ中的訊息都只能儲存在Queue(佇列)中
Producer(生產者)
傳送的訊息最終會投遞到Queue(佇列)
中(從上圖可以看出Producer並不直接與Queue直接互動),Consumer(消費者)
可以從Queue(佇列)
中獲取訊息並消費- 多個
Consumer(消費者)
可以訂閱同一個Queue(佇列)
,此時佇列中的訊息會被平均分配(Round-Robin,輪詢)給多個Consumer(消費者)
處理,RabbitMQ
不支援佇列層面的廣播消費。
Exchange
Producer(生產者)
會將訊息傳送給Exchange(交換器)
,由Exchange(交換器)
將訊息路由到一個或者多個Queue(佇列)
(或者丟棄)。因為訊息是儲存在Queue(佇列)
Exchange(交換器)
的使用並不真正的消耗伺服器的效能,而Queue(佇列)
會。
2. RoutingKey(路由鍵)
: Producer
將訊息傳送給Exchange(交換器)
時一般會指定一個RoutingKey(路由鍵)
用來指定這個訊息的路由規則,而這個RoutingKey(路由鍵)
需要與交換器型別、BindingKey(繫結鍵)
聯合使用,最終才能到相應的Queue(佇列)
3. BindingKey(繫結鍵)
:RabbitMQ Broker
通過BindingKey(繫結鍵)
將Exchange(交換器)
與Queue(佇列)
關聯起來,這樣RabbitMQ Broker
就知道如何正確地將訊息路由到那個Queue(佇列)
了
4. 當RoutingKey(路由鍵)
與BindingKey(繫結鍵)
相匹配時,訊息會被路由到對應的佇列中。在繫結多個佇列到同一個Exchange(交換器)
的時候,這些繫結允許使用相同的BindingKey(繫結鍵)
,BindingKey(繫結鍵)
是否有效取決於Exchange(交換器)
的型別,比如fanout
型別的Exchange(交換器)
無論BindingKey(繫結鍵)
是什麼都會將訊息路由到所有繫結到該Exchange(交換器)
的Queue(佇列)
中。
5. BindingKey(繫結鍵)
官方解釋是繫結的時候使用的RoutingKey(路由鍵)
,大多數時候都把BindingKey(繫結鍵)
和RoutingKey(路由鍵)
看做RoutingKey(路由鍵)
,事實上RabbitMQ java API
中只有RoutingKey(路由鍵)
,並沒有BindingKey(繫結鍵)
,在API呼叫的時候需要自己辨別。
6. 發信人(Producer)
填寫在包裹上的地址(RoutingKey)
和真實存在的地址(BindingKey)
相匹配時,這個包裹就會被正確的投遞到目的地(Queue)
,如果匹配不上,就不會投遞到目的地(Queue)
Exchange常見型別
fanout
fanout型別
的交換器會把所有傳送到該Exchange
的訊息路由到所有與它繫結的Queue(佇列)
中。下圖中,生產者(P)傳送到Exchange(X)的所有訊息都會路由到圖中的兩個Queue,並最終被兩個消費者(C1與C2)消費。
direct
direct型別
的Exchange交換器
會把訊息路由到那些BindingKey(繫結鍵)
與RoutingKey(路由鍵)
完全匹配的Queue(佇列)
中。- 以上圖的配置為例,我們以
RoutingKey="error"
傳送訊息到Exchange
,則訊息會路由到Queue1(amqp.gen-S9b…,這是由RabbitMQ自動生成的Queue名稱)和Queue2(amqp.gen-Agl…);如果我們以RoutingKey="info"
或RoutingKey="warning"
來發送訊息,則訊息只會路由到Queue2。如果我們以其他RoutingKey
傳送訊息,則訊息不會路由到這兩個Queue
中。
topic
topic型別
的Exchange(交換器)
在匹配規則上進行了擴充套件,它與direct型別
的Exchange交換器
相似,也是將訊息路由到BindingKey(繫結鍵)
與RoutingKey(路由鍵)
相匹配的Queue(佇列)
中,但這裡的匹配規則有些不同,它約定:RoutingKey(路由鍵)
為一個句點號"."
分隔的字串(我們將被句點號"."
分隔開的每一段獨立的字串稱為一個單詞),如"stock.usd.nyse"
、"nyse.vmw"
、"quick.orange.rabbit"
。BindingKey(繫結鍵)
與RoutingKey(路由鍵)
一樣也是句點號"."
分隔的字串。BindingKey(繫結鍵)
中可以存在兩種特殊字元"*"
與"#"
,用於做模糊匹配,其中"*"
用於匹配一個單詞,"#"
用於匹配多個單詞(可以是零個)。- 圖示
- 以上圖中的配置為例,
routingKey="quick.orange.rabbit"
的訊息會同時路由到Q1與Q2,routingKey="lazy.orange.fox"
的訊息會路由到Q1,routingKey="lazy.brown.fox"
的訊息會路由到Q2,routingKey="lazy.pink.rabbit"
的訊息會路由到Q2(只會投遞給Q2一次,雖然這個RoutingKey(路由鍵)
與Q2的兩個BindingKey(繫結鍵)
都匹配).routingKey="quick.brown.fox"
、routingKey="orange"
、routingKey="quick.orange.male.rabbit"
的訊息將會被丟棄,因為它們沒有匹配任何BindingKey(繫結鍵)
。
- 以上圖中的配置為例,
headers
headers
型別的Exchange(交換器)
不依賴於RoutingKey(路由鍵)
的匹配規則來路由訊息,而是根據傳送的訊息內容中中headers
屬性進行匹配。Queue
與Exchange
繫結時指定的key-value
鍵值對,如果完全匹配訊息傳送到Exchange
時訊息內容中的headers
屬性(key-value
鍵值對),則訊息會路由到該佇列。headers
型別的Exchange(交換器)
效能很差,一般情況下不會使用
Virtual hosts
- 每個
virtual host
本質上都是一個RabbitMQ Server
,擁有它自己的queue
,exchagne
,和繫結規則等等。這保證了你可以在多個不同的Application
中使用RabbitMQ
。
docker安裝
-
安裝
$ docker run -d --name rabbitmq-3.6.15-management -p 15671:15671 -p 15672:15672 -p 5671:5671 -p 5672:5672 rabbitmq:3.6.15-management
-
訪問http://jannal.mac.com:15672/