比如用戶註冊，註冊完成後發送通知郵件。如果不使用消息隊列：
1.檢查用戶註冊信息的合法性，如果合法則將註冊信息寫入數據庫中，若不合法，直接返回，流程結束；
2.將用戶註冊信息寫入數據庫後，給用戶發送通知郵件，以告知用戶註冊的相關信息，比如註冊賬號等信息。
註冊消息寫入數據庫和發送通知郵件這兩個組件間是直接交互，且是同步通信方式。那麼，從用戶提交註冊到收到響應，需要等系統完成這兩個步驟。
引入消息隊列作爲註冊消息寫入數據庫和發送通知郵件這兩個組件間的中間通信者，那麼這兩個組件就可以實現異步通信、異步執行。
1.檢查用戶註冊信息的合法性，如果合法則將註冊信息寫入數據庫中，若不合法則直接返回，流程結束；
2.註冊消息寫入消息數據庫後，將消息寫入消息隊列的隊尾；
3.發送通知郵件的組件去消息隊列取出隊首的消息，給用戶發送通知郵件，告知用戶註冊的相關信息。
也就是說，採用消息隊列模式，只需要第 2 步完成，即可給用戶返回響應。第 3 步發送通知郵件可以在返回響應之後執行。
用戶的註冊信息寫入數據庫之後，通過數據庫的可靠性設計來保證用戶註冊信息不會丟失，也就是說發送通知郵件的組件一定可以獲取到用戶註冊信息，即保證會給註冊用戶發送通知郵件。也就是說，消息隊列的引入不會影響用戶註冊網站，但會提升用戶響應效率。
消息隊列是基於隊列實現的，存儲具有特定格式的消息數據，比如定義一個包含消息類型、標誌消息唯一性的 ID、消息內容的一個結構體作爲消息數據的特定格式。消息以特定格式放入這個隊列的尾部後可以直接返回，並不需要系統馬上處理，之後會有其他進程從隊列頭部開始讀取消息，按照消息放入的順序逐一處理。
消息隊列工作原理
生產者。生產者會產生消息或數據，並將消息或數據插入到消息隊列中。
消息隊列。一種具有先進先出特點的數據結構，用於存儲消息。
消費者。從消息隊列中獲取消息或數據，進行相關處理。
RocketMQ 消息隊列原理及工作機制
RokcetMQ 共包括 NameServer Cluster、Producer Cluster、Broker Cluster 和 Consumer Cluster 共 4 部分
NameServer Cluster，名字服務器集羣。提供分佈式服務的協同和管理功能，在 RocketMQ 中主要是管理 Broker 的信息，包括有哪些 Broker、Broker 的地址和狀態等，以方便生產者獲取 Broker 信息發佈消息，以及訂閱者根據 Broker 信息獲取消息。
Producer Cluster，生產者集羣。負責接收用戶數據，然後將數據發佈到消息隊列中心 Broker Cluster。
Consumer Cluster，消費者集羣。負責從 Broker 中獲取消息進行消費。
Broker Cluster，Broker 集羣。負責存儲 Producer Cluster 發佈的數據，以方便消費者進行消費。
在 Broker Cluster 中，消息的存儲採用主題（Topic）+ 消息隊列（Queue）的方式實現：
一個主題可以分區，分佈在各個不同的 Broker 中，每個 Broker 上只有該主題的部分數據。每個主題分區中，隊列的數量可以不同，由用戶在創建主題時指定。隊列是資源分配的基本單元，消息進行存儲時會存放到相應主題的分區中。
RocketMQ 的工作流程
1.首先啓動 NameServer，然後啓動 Broker。Broker 啓動後，會主動找 NameServer 建立連接，並將自己的信息註冊到 NameServer 上。註冊完畢後，Broker 會週期性地給 NameServer 發送心跳包，比如每隔 1s 發送一次，以告知 NameServer 自己還活着；心跳包裏還可以包括 Broker 當前存儲的數據信息，也就是說 Broker 可以週期性地向 NameServer 更新自己的數據信息，以保證 NameServer 上存儲的數據是最新的。
2，創建主題，並確定這個主題的數據放入哪些 Broker 中。
3.當 Producer 生產消息發送到主題時，需要先到 NameServer 查詢該主題存放在哪些 Broker 中，獲取到相關 Broker 信息後，將消息發送給這些 Broker 進行存儲。
4.Consumer 要從主題消費消息，也需要首先到 NameServer 查詢一下該主題的消息存儲在哪些 Broker 上，然後去相應的 Broker 獲取消息進行消費。
消息隊列模式，是根據消費者需求到消息隊列獲取數據消費的，消費者只需要知道消息隊列地址即可，消息隊列中心也無需提前知道消費者信息。消息隊列這種模式對消費者沒有特別需求，因此比較適合消費者爲臨時用戶的場景。比如目前，阿里內部將 RocketMQ 應用於購物交易、充值、消息推送等多個場景，因爲在這些場景下，每個消費者不是常駐進程或服務，幾乎都是臨時存在。
消息隊列模式中採用了具有先進先出特徵的隊列結構進行存儲，而訂閱發佈採用了 map 或數組等方式存儲。
對於消息隊列模式，消息隊列中心無需提前獲取消費者信息，因此對消費者比較靈活，適合消費者爲臨時用戶的場景；
發佈訂閱模式，需要消費者提前向消息中心訂閱消息，也就是說消息中心需要提前獲取消費者信息，適合消費者爲長駐進程或服務的場景。