認識一下 RabbitMQ

分佈式系統中，如何在各個應用之間高效的進行通訊，是系統設計中的一個關鍵。

使用 消息代理（message broker） 是一個優雅的解決方案。

RabbitMQ 就是一個被普遍應用的消息代理，遵循 AMQP協議。

接下來咱們就瞭解一下：

• Message Broker 概念
• AMQP 協議的核心構成
• 消息轉發的 4 種模式

1. Message Broker

broker 是經紀人的意思，促成賣方、買方的交易，例如房產經紀人。

消息模型中，有消息的生產者、消費者，就至關於賣方、買方。

因此，也須要一個消息經紀人，這就引出了 message broker 的概念。

message broker 從生產者接收消息，再發送給消費者，這樣，生產者、消費者能夠徹底隔離。

RabbitMQ 就是一個 message broker。

2. AMQP

具體如何傳遞消息？要看使用的消息協議。

RabbitMQ 支持多種協議，其中最重要的是 AMQP（Advanced Message Queuing Protocol）。

AMQP 的概念模型很簡單，包含3個部分：

• Queue
• Binding
• Exchange

當一個消息發佈到 RabbitMQ 後，首先到達 Exchange，而後 Exchange 把消息分配給 Queue，消費者從 Queue 中獲得消息。

AMQP 是一個可編程的協議，咱們能夠自由配置 exchange, binding, queue。

2.1 Queue 隊列

Queue 是先進先出數據結構。

Queue 是 RabbitMQ 存儲消息的地方。

Queue 能夠靈活的配置，例如：

• 設置 name
• 配置可靠模式，即便 broker 宕機也能夠保障數據安全
• 消息自動刪除
• 獨佔模式
• ……

2.3 Consumer 消費者

一個 queue 能夠同時鏈接多個 consumer。

consumer 既能夠本身從 queue 拉取消息，也能夠由 queue 主動把消息推給 consumer。

2.4 Binding 綁定

Binding 是 Queue 與 Exchange 創建鏈接的規則。

每一個 Queue 都會與一個默認 Exchange 鏈接，咱們能夠爲這個 Queue 鏈接更多的 Exchange。

Exchange 經過 Binding 規則，把消息路由到相應的 Queue。

2.5 Exchange

Exchange 是 RabbitMQ 的消息網關。

Exchange 就像是一個接線員，收到消息後決定如何轉發。

主要有 4 種轉發類型：

• Direct
• Fanout
• Topic
• Header

下面具體瞭解一下。

3. 消息轉發模式

3.1 Direct 直傳

Routing key == Binding key

• routing key 是消息的一個屬性。
• binding key 是綁定 queue 與 exchange 時指定的。

生產者（綠色球）發送了一個消息，帶着一個 routing key -- img.resize。

當消息到達 exchange（桔色球）後，exchange 會查找全部帶着 img.resize 這個 Binding key 的 queue。

找到匹配的 queue 以後，消息就會被髮送給這些 queue。

若是沒找到，消息會被退回給生產者，或者丟棄。

消息到達指定的 queue 以後，會以輪詢的形式分派給消費者（resizer.1/resizer.2），確保負載均衡。

3.2 Fanout 扇形

此方式會忽略 routing key，把消息分派給全部鏈接的 queue。

最多見的場景就是消息廣播。

注意，此方式是 exchange 廣播給 queue，不是 queue 廣播給 consumer。queue 到 consumer 仍是輪詢的方式。

3.3 Topic 主題

routing key 與 binding key 進行模式匹配。

Routing key == Pattern in binding key

RabbitMQ 使用 * 和 # 這2個通配符。

* - 匹配一個詞。

# - 匹配 0 個或多個詞。

routing key 爲 logs.error 的消息，匹配 binding key -- logs.error 和 logs.*，因此消息會進入 "only error" 和 "alllogs"。

routing key 爲 logs.success 的消息，匹配binding key -- #success 和 logs.*，因此消息會進入 "only success" 和 "alllogs"。

這種形式有很是多的應用場景，能夠用於發佈-訂閱模式、將相關數據分發給指望的 worker 等等。

3.4 Header

一種特殊類型的 exchange，基於消息頭中的 key 進行路由。

使用這種方式後，就會忽略消息的 routing key 屬性。

對一個 header exchange 建立 binding 時，能夠對一個 queue 綁定多個 header，這種狀況下，消息生產者須要告訴 RabbitMQ 匹配哪些 key，producer 能夠指定一個標識 x-match，值能夠是：

• any - 只有一個值應該匹配。
• all - 全部值都必須匹配。

4. 消息確認

消息到達目的地以後，broker 應該從隊列中將其刪除，這是爲了防止消息過多致使溢出。

刪除消息以前，broker 必須獲得確認通知。

有 2 種通知方式：

• 自動通知：只要 consumer 接收到消息便可，無論是否處理完成。
• 明確顯示通知：只有在 consumer 發送回來一個確認信息後才能夠，這樣保證 consumer 處理完成後再刪除。

推薦閱讀：

• 架構設計原則 - 高併發
• 架構設計 -- 服務降級
• 接口級故障處理策略
• 高併發的經常使用策略
• 分佈式惟一ID的生成方案