如：注冊用戶這種服務，它可能解耦成好幾種獨立的服務（賬號驗證，郵箱驗證碼，手機短信碼等）。它們作為消費者，等待用戶輸入數據，在前臺數據提交之后會經過分解并發送到各個服務所在的url，分發的那個角色就相當于生產者。消費者在獲取數據時候有可能一次不能處理完，那么它們各自有一個請求隊列，那就是內存緩沖區了。做這項工作的框架叫做消息隊列。 又比如：電商系統中的訂單處理系統，傳統處理模式是：下訂單的時候，訂單系統可能會調用庫存系統的接口，這樣兩個系統之間存在一個嚴重依賴關系，如果庫存系統宕機，那么整個流程都會受到影響。現在大多公司的處理方法是：引入消息隊列，下完訂單，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。 幾個概念說明： Broker：簡單來說就是消息隊列服務器實體。 　　Exchange：消息交換機，它指定消息按什么規則，路由到哪個隊列。 　　Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。 　　Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。 　　Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。 　　vhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的權限分離。 　　producer：消息生產者，就是投遞消息的程序。 　　consumer：消息消費者，就是接受消息的程序。 　　channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。 消息隊列的使用過程大概如下： （1）客戶端連接到消息隊列服務器，打開一個channel。 　　（2）客戶端聲明一個exchange，并設置相關屬性。 　　（3）客戶端聲明一個queue，并設置相關屬性。 　　（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。 　　（5）客戶端投遞消息到exchange。 exchange接收到消息后，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。 exchange也有幾個類型，完全根據key進行投遞的叫做Direct交換機，例如，綁定時設置了routing key為”abc”，那么客戶端提交的消息，只有設置了key為”abc”的才會投遞到隊列。對key進行模式匹配后進行投遞的叫做Topic交換機，符號”#”匹配一個或多個詞，符號”*”匹配正好一個詞。例如”abc.#”匹配”abc.def.ghi”，”abc.*”只匹配”abc.def”。還有一種不需要key的，叫做Fanout交換機，它采取廣播模式，一個消息進來時，投遞到與該交換機綁定的所有隊列。 RabbitMQ支持消息的持久化，也就是數據寫在磁盤上，為了數據安全考慮，我想大多數用戶都會選擇持久化。消息隊列持久化包括3個部分： 　　（1）exchange持久化，在聲明時指定durable => 1 　　（2）queue持久化，在聲明時指定durable => 1 　　（3）消息持久化，在投遞時指定delivery_mode => 2（1是非持久化） 如果exchange和queue都是持久化的，那么它們之間的binding也是持久化的。如果exchange和queue兩者之間有一個持久化，一個非持久化，就不允許建立綁定。