1. p：生成者，生成消息的程序
2. c：消費者，消費消息的程序
3. Queue：消息隊列，用于緩存消息，生產者向里面投遞消息，消費者從里面拿取消息消費
4. X：交換機，在rabbitMQ中，實際上是把生成者的消息先發送到交換機上面，然后在按照一定的規則路由到一個或者多個隊列中，相關概念：[[交換機類型]]

simple(簡單模式)

1. 一個生產者，一個消費者
2. 適用場景:消息只能被單個消費者處理

此處省略了exchange交換機，在rabbitmq中是一定有交換機的，其他的可能沒有

Work Queue(工作隊列)

1. 一個生產者，多個消費者
2. 多消息的情況下，Work Queue 會將消息分派給不同的消費者，每個消費者都會接收到不同的消息
3. 特點：消息不會重復，分配給不同的消費者
4. 使用場景：在集群環境中做異步處理

此處省略了exchange交換機，在rabbitmq中是一定有交換機的，其他的可能沒有

比如在12306短信通知服務，訂票成功后，訂單消息會發送到RabbitMQ，短信服務從RabbitMQ中獲取訂單消息，并且發送消息

Publish/Subscribe(發布/訂閱)

1. 一個生產者，多個消費者
2. X代表交換機消息復制多份，每個消費者接收相同的消息
3. 生產者發送一條消息，經過交換機轉發到不同的隊列，多個不同隊列就有多個不同的消費者（無條件）
4. 適合場景：消息需要被多個消費者同時接收的場景，如實時通知或者廣播消息

Routing(路由模式)

1. 路由模式是發布訂閱模式的變種，在其基礎上添加了RoutingKey
2. 相比于前者的無條件分發消息，路由模式根據Exchange的RoutingKey的規則將數據篩選后發送給對應的消費者隊列
3. 使用場景：需要特定規則分發消息的場景

Topic(通配符模式)

1. 在routingKey的基礎上，增添[[交換機類型#^8c5d09|通配符]]的功能，使得匹配規則更加靈活
2. 交換機通過RoutingKey將消息轉發給RoutingKey匹配的隊列
3. 適用場景：需要靈活匹配和過濾消息的場景

[!QUESTION] Routing和Topic有什么不同？
不同之處：routingKey的匹配方式不同。Routing模式是相等匹配，topics模式是通配符匹配

RPC(Remote Procedure Call)

1. 當客戶端啟動時，它會創建一個獨占的回調隊列。
2. 對于 RPC 請求，客戶端發送一個包含兩個屬性的消息： reply_to，該屬性設置為回調隊列，以及 correlation_id，該屬性為每個請求設置一個唯一值。
3. 請求被發送到一個 rpc_queue 隊列。
4. RPC 工作進程（又名：服務器）正在該隊列上等待請求。當請求出現時，它會執行任務，并使用來自 replyTo 字段的隊列將結果消息發送回客戶端。
5. 客戶端在應答隊列上等待數據。當消息出現時，它會檢查 correlationId 屬性。如果它與請求中的值匹配，則將響應返回給應用程序。

Publisher Confirms(發布確認模式)

Publisher Confirms模式是RabbitMQ提供的一種確保消息可靠發送到RabbitMQ服務器的機制。在這種模式下，生產者可以等待RabbitMQ服務器的確認，以確保消息已經被服務器接收并處理。

1. 生產者將Channel設置為confirm模式(通過調用channel.confirmSelect()完成)后，發布的每一條消息都會獲得一個唯一的ID，生產者可以將這些序列號與消息關聯起來，以便跟蹤消息的狀態。
2. 當消息被RabbitMQ服務器接收并處理后，服務器會異步地向生產者發送一個確認(ACK)給生產者(包含消息的唯一ID)，表明消息已經送達。
3. 通過Publisher Confirms模式，生產者可以確保消息被RabbitMQ服務器成功接收，從而避免消息丟失的問題。
4. 適用場景：對數據安全性要求較高的場景。比如金融交易，訂單處理。