在前面的章節中我們簡單介紹過一些RabbitMQ的工作模式，RabbitMQ共提供了七種工作模式進行消息傳遞，這里我們來詳細介紹。

1. Simple(簡單模式)

P：生產者

C：消費者

特點：一個生產者一個消費者，消息只能被消費一次，也稱為點對點（Point-to-Point）模式。我們上期寫的示例就是這個模式

適用場景：消息只能被單個消費者處理。

2. Work Queue（工作隊列）?

一個生產者，多個消費者，將消息分給不同的消費者，每個消費者收到不同的消息。

特點：消息不會被重復處理

使用場景：集群環境中做異步處理，例如12306短信通知服務，訂票成功后，訂單消息會發送給RabbitMQ，短信服務從RabbitMQ中獲取訂單信息并發送通知信息?。

3. Publish/Subscribe(發布/訂閱)

?X表示交換機，生產者將消息發送給Exchange，由交換機按一定的規則路由到一個或多個隊列中。

特點：一個生產者多個消費者，生產者發送一條消息，交換機（Fanout）轉發給所有綁定的隊列。

適用場景：消息需要被多個消費者同時接收的場景，如實時通知或者廣播消息。例如電商平臺下單后，同時觸發 “用戶通知”“庫存扣減”“訂單統計” 多個操作。

RabbitMQ有四種類型的交換機，不同類型有不同的路由策略：

1. Fanout：廣播，將消息交給所有綁定到交換機的隊列（Publish/Subcribe模式）
2. Direct：定向，把消息交給符合指定routing key的隊列（Routing模式）
3. Topic：通配符，把消息交給符合routing pattern（路由模式）的隊列（Topics模式）
4. Headers：headers類型的交換機不依賴于路由鍵的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配，headers類型的交換機性能會很差，而且也不實用，基本不會看到它的存在。

Exchange只負責轉發消息，不具備存儲消息的能力，因此如果沒有任何隊列與Exchange綁定，或者沒有符合路由規則的隊列，那么消息就會丟失

注意：簡單模式 和 工作隊列模式 也會使用交換機轉發消息，不會在生產者把消息直接發送給隊列的情況，通常這兩種模式使用的是Direct交換機，routing key通常為隊列名。

• routing key：路由鍵，生產者將消息發送給交換機時指定的一個字符串，用來告訴交換機把消息轉發到哪個隊列。每個消息只能有一個routing key
• binding key：綁定，隊列在綁定到交換機時，需要指定 BindingKey 作為匹配規則，只接收routing key對應的消息。一個隊列可以有多個binding key，通過多次綁定實現

?4. Routing（路由模式）

路由模式是發布訂閱模式的變種，在發送訂閱的基礎上，增加routing key，發布訂閱模式是無條件將消息轉發給所有隊列，路由模式Exchange會根據routing key的規則來轉發。

適用場景，需要根據特定規則分發消息的場景，例如系統打印日志，日志等級分為error,warning,info,debug,就可以通過這種模式把不同日志發送到不同的隊列，最終輸出到不同的文件。

5. Topics（通配符模式）

路由模式的升級版，在 Routing的基礎上，增加了通配符的功能，即隊列的bingding key可以寫作通配符的模式來匹配不同的routing key

通配符規則：

• *（星號）：匹配一個單詞（如"order.*"匹配"order.create"但不匹配"order.create.success"）。
• #（井號）：匹配零個或多個單詞（如"order.#"匹配所有以"order."開頭的 Routing Key）。

適用場景：需要靈活匹配和過濾消息的場景?

6. RPC（RPC通信）?

在PRC通信中，沒有生產者和消費者，通過兩個隊列實現了一個遠程過程調用

1. 客戶端發送請求：將請求消息發送到服務端隊列，并附帶一個回調隊列地址和唯一請求 ID（correlation ID）。
2. 服務端處理并響應：接收請求、處理邏輯，然后將結果發送到回調隊列，同時攜帶相同的 correlation ID。
3. 客戶端匹配響應：根據 correlation ID 將響應與請求關聯，實現 “偽同步” 效果。

?

適用場景：

• 需要異步解耦但又需即時結果的場景。例如微服務間的輕量級通信。
• 跨語言服務調用（RabbitMQ 支持多語言客戶端）。

7. Publisher Confirms（發布確認）

Publisher Confirms模式是RabbitMQ提供的一種確保消息可靠發送到RabbitMQ服務器的機制，在這種模式下，生產者可以等待RabbitMQ服務器的確認，確保消息已經被服務器接收并處理。在默認模式下，生產者發送消息后不會收到任何反饋，若網絡故障或交換機異常，消息可能丟失。而發布確認機制可以解決這一問題：

1. 生產者發送消息：生產者將Channel設置為confirm模式后，發送消息會附帶唯一的序列號（Sequence Number）。
2. RabbitMQ 確認：交換機收到消息后，異步返回一個確認幀（Confirm Frame），包含相同的序列號。
3. 生產者處理確認：根據序列號匹配確認結果，標記消息為 “已確認” 或 “未確認”。

適用場景：對數據安全性要求高的場景，例如金融交易，訂單處理?