RabbitMQ 一共有 7 中工作模式，可以先去官網上了解一下（一下截圖均來自官網）：RabbitMQ 官網
Simple
- P：生產者，要發送消息的程序；
- C：消費者，消息的接受者；
- hello：要發送的消息，這個消息存在在一個隊列中；
“簡單模式”：這種模式的消息只能被消費一次，也稱為“點對點”模式（Point-to-Point），適用于消息只能被單個消費者處理的場景，并且也是最簡單的一種模式。
Work Queue
這中模式叫做“工作隊列模式”，從圖上看就可以發現它是一對多模型，一個生產者，多個消費者，生產者產生的消息是由多個消費者共同消費的，也就是所消息的總量是不會變的，適合集群環境中做異步處理。比如一個訂單服務，下單成功之后，訂單消息就會發送到 RabbitMQ ，然后訂單服務就會從 RabbitMQ 中獲取訂單詳情并進行下一步的處理（在多個訂單服務之間進行分配）。
Publish/Subscribe
這種叫“發布/訂閱模式”，相比于“工作隊列模式”只是在生產者和隊列之間加一層 X （交換機）。
交換機（Exchange）的作用就是將生產者發送的消息按照一定的規則路由到一個或多個隊列中，它只負責轉發消息，不具備存儲消息的能力，因此如果沒有任何隊列與 Exchange 綁定，或者沒有符合路由規則的隊列，那么消息就會丟失；RabbitMQ 的交換機一共有一下幾種類型：
- fanout：廣播類型，將所有消息交給所有綁定到交換機的隊列（發布/訂閱模式）；
- direct：定向路由類型，把消息交給符合指定 routing key 的隊列；
- topic：通配符類型，把消息交給符合 routing pattern （路由模式）的隊列；
- headers：這個類型的交換機不依賴于路由鍵的匹配規則來路由消息，而是根據發送的消息內容中的 headers 屬性進行匹配，但是這個交換機的性能較差使用頻率也少；
這里還有兩個概念就是 RountingKey 和 BindingKey：
- RoutingKey：路由鍵，生產者將消息發送給交換器的時候會指定路由鍵，然后交換機就會根據這個路由鍵去決定下一步該怎么做；
- BaindingKey：綁定鍵，通過 BindingKey 將交換機與隊列關聯起來，在綁定的時候一般會指定一個 BindingKey，這樣 RabbitMQ 就可以根據 RoutingKey 和 BindingKey 來正確轉發消息到指定的隊列中；
Routing
這種叫“路由模式”，在“發布/訂閱模式”的基礎上，增加 RoutingKey，發布訂閱模式就是直接把消息全部發送到與交換機關聯的隊列中，沒有其他規則判斷；路由模式下，Exchange 會根據用戶傳過來的 RoutingKey 和交換機與隊列綁定的 BindingKey 進行比較，只有相同的話才會把消息發送到對應對立中，適合需要根據特定規則分發消息的場景；
Topics
這種叫做“通配符模式”，如果理解了上面的“路由模式”的話理解這個應該不難，它比“路由模式”更加靈活，Exchange 可以根據使用通配符的方式對消息路由到指定隊列，比如要是 RoutintKey ：test.orange.rabbit 的話，那么 Exchange 會將消息發送到 Q1 和 Q2 中；
RPC
RPC 通訊就是客戶端去遠程調用服務器的服務，在通訊過程中，沒有生產者和消費者；客戶端發送消息到一個指定的隊列（request queue），并在消息屬性中設置 replyTo 字段，這個字段的意思就是指定一個回調隊列用于接收服務端的響應，然后服務端接收到請求之后，處理請求并發送響應消息到 replyTo 指定的回調隊列中，客戶端再再回調隊列上等待響應消息，一旦收到消息，客戶端就會檢查消息的 correlationId 屬性，以確保它是期望的響應，其中?correlationId 的值也是客戶端定義的，然后服務端再根據約定好的規則進行檢查；
Publisher Confirms
“發布確認模式”是 RabbitMQ 提供的一種確保消息可靠發送到 RabbitMQ 服務器的機制。在這中模式下，生產者可以等待 RabbitMQ 服務器的確認，確保消息已經被正確接收并處理：
- 生產者將 channel 設置為 confirm 模式，發布的每一條消息都會獲得一個唯一的ID，生產者可以將這些序列號與消息關聯起來，用來跟蹤消息的狀態。
- 當消息被 RabbitMQ 服務器接收并處理后，服務器會異步的向生產者發送一個確認 ACK 給生產者（包含消息的唯一ID），表明消息已經正確到達。
通過 Publisher Confirm 模式，可以避免消息丟失的場景，適合對數據安全性較高的場景如金融交易和訂單處理等等。
)
