一、rabbitMQ支持的消息模型如下

第一種模型(直連)

在上圖的模型中，有以下概念：

• P：生產者，也就是要發送消息的程序
• C：消費者：消息的接受者，會一直等待消息到來。
• queue：消息隊列，圖中紅色部分。類似一個郵箱，可以緩存消息；生產者向其中投遞消息，消費者從其中取出消息。

第二種模型(work quene)
Work queues，也被稱為（Task queues），任務模型。當消息處理比較耗時的時候，可能生產消息的速度會遠遠大于消息的消費速度。長此以往，消息就會堆積越來越多，無法及時處理。此時就可以使用work 模型：讓多個消費者綁定到一個隊列，共同消費隊列中的消息。隊列中的消息一旦消費，就會消失，因此任務是不會被重復執行的。

角色：

• P：生產者：任務的發布者
• C1：消費者-1，領取任務并且完成任務，假設完成速度較慢
• C2：消費者-2：領取任務并完成任務，假設完成速度快

第三種模型(fanout(廣播))

在廣播模式下，消息發送流程是這樣的(P為生產者、X為交換機，C為消費者)：

• 可以有多個消費者
• 每個消費者有自己的queue（隊列）
• 每個隊列都要綁定到Exchange（交換機）
• 生產者發送的消息，只能發送到交換機，交換機來決定要發給哪個隊列，生產者無法決定。
• 交換機把消息發送給綁定過的所有隊列
• 隊列的消費者都能拿到消息。實現一條消息被多個消費者消費

適用于注冊完，返回給用戶，后臺再執行發郵箱驗證，手機驗證等操作。或者下完單后，相對應的庫存操作和訂單操作等。

第四種模型(Routing(路由))
4.1 Routing 之訂閱模型-Direct(直連)

在Fanout模式中，一條消息，會被所有訂閱的隊列都消費。但是，在某些場景下，我們希望不同的消息被不同的隊列消費。這時就要用到Direct類型的Exchange。
在Direct模型下：

• 隊列與交換機的綁定，不能是任意綁定了，而是要指定一個RoutingKey（路由key）
• 消息的發送方在 向 Exchange發送消息時，也必須指定消息的 RoutingKey。
• Exchange不再把消息交給每一個綁定的隊列，而是根據消息的Routing Key進行判斷，只有隊列的Routingkey與消息的 Routing key完全一致，才會接收到消息

流程:

4.2 Routing 之訂閱模型-Topic
Topic類型的Exchange與Direct相比，都是可以根據RoutingKey把消息路由到不同的隊列。只不過Topic類型Exchange可以讓隊列在綁定Routing key 的時候使用通配符！這種模型Routingkey 一般都是由一個或多個單詞組成，多個單詞之間以”.”分割，例如： item.insert

# 統配符* (star) can substitute for exactly one word. 匹配不多不少恰好1個詞# (hash) can substitute for zero or more words. 匹配一個或多個詞 # 如:audit.# 匹配audit.irs.corporate或者 audit.irs 等audit.* 只能匹配 audit.irs

二、總圖方便記憶

總結

以上是生活随笔為你收集整理的RabbitMQ支持的消息模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。