10分鐘就能輕鬆入門消息中間件rabbitmq（附帶教學源碼）

rabbitmq簡介

rabbitmq 是spring所在公司Pivotal自己的產品。因爲跟spring有共同的血緣關係，所以spring 全家桶對其的支持應該是相當完善的。本身基於AMQP高級隊列協議的消息中間件，採用erlang開發，因此安裝需要erlang環境。具體安裝根據自己的環境。

使用場景

一、異步處理

用戶註冊（50ms），還需發送郵件（50ms）和短信（50ms）

串行：（150ms）用戶註冊—》發送郵件----》發送短信

並行（100ms）：用戶註冊—》發送郵件

a) |----》發送短信

消息中間件（56ms）：

用戶註冊（50ms）—》（6ms）消息中間件《-----發送郵件《-----發送短信

說明：一個用戶註冊流程，包含下述業務：

1. 註冊處理以及寫數據庫、

2. 發送註冊成功的手機短信

3. 發送註冊成功的郵件信息

我們使用老方法的話，則會註冊完執行發送短信再執行郵件發送。太low

一般使用的是：在註冊成功後，使用兩個線程去做發送郵件，發送短信操作。

如果用消息中間件：則將兩個線程創建這些事情省了，直接發送消息給消息中間件，然後讓郵件服務和短信服務自己去消息中間件裏面去取消息，然後取到消息後再自己做對應的業務操作。就是這麼方便

二、應用解耦

a) 訂單系統---》庫存系統（強耦合）

b) 消息中間件：訂單系統---》消息中間件《----庫存系統（解耦）

說明：用戶購買一筆訂單，訂單成交—》調用庫存系統—1---》返回給訂單系統，此時算一個正常業務。還有不正常的業務，就是用戶訂單完成後，訂單系統並不去滴啊用庫存系統-1操作，而是調用消息中間件，寫入一個訂單信息。又庫存系統自己去消息中間件上去獲取，然後更新庫存，這樣能夠減少互聯網型應用追求的快這一個屬性。而庫存系統讀取訂單間庫存其實這個操作也是非常快的，所以有消息中間件對解耦來說也是一個不錯的方向。

三、流量削峯

a) 用戶請求-----》秒殺應用

b) 應用的前端加入消息隊列

c) 用戶請求-----》消息隊列《----秒殺應用

說明：比如，系統舉行秒殺活動，熱門商品。流量蜂擁而至 100件商品，10萬人擠進來怎麼辦，10萬秒殺的操作，放入消息隊列。秒殺應用處理消息隊列中的10萬個請求中的100個，其他的打回，通知失敗。流量峯值控制在消息隊列處，秒殺應用不會瞬間被懟死.

四、日誌處理

a) 錯誤日誌---》消息隊列《----日誌處理

b) 用戶行爲日誌--》消息隊列《-----日誌的存儲或流式處理

說明：日誌處理但是一般是另一種消息中間件kafka，非常強大。

五、基於事件的消息發送

可以搞廣播，點對點，延時消費、分佈式事務等

簡單概念

一般消息隊列都是生產者將消息發送到隊列，消費者監聽隊列進行消費。rabbitmq 一個虛擬主機（默認 /）持有一個或者多個交換機（Exchange，用戶只能在虛擬主機的粒度進行權限控制。交換機根據一定的策略（RoutingKey）綁定(Binding)到隊列(Queue)上，這樣生產者和隊列就沒有直接聯繫。而是將消息發送的交換機，交換機再把消息轉發到對應綁定的隊列上。此處需要詳細熟悉rabbitmq的工作流程，不清楚可以找相關資料進行學習。

上面說了 Exchange 作爲rabbitmq的一個獨特的重要的概念，我們常用的有四種

這四種的說明

Direct: 先策略匹配到對應綁定的隊列後，纔會被投送到該隊列。交換機跟隊列必須是精確的對應關係，這種最爲簡單。
Topic: 轉發消息主要是根據通配符。在這種交換機下，隊列和交換機的綁定會定義一種路由模式，那麼，通配符就要在這種路由模式和路由鍵之間匹配後交換機才能轉發消息這種可以認爲是Direct 的靈活版。
Headers:也是根據規則匹配, 相較於 direct 和 topic 固定地使用 routingkey , headers 則是一個自定義匹配規則的類型。
在隊列與交換器綁定時會設定一組鍵值對規則。消息中也包括一組鍵值對( headers 屬性) 當這些鍵值對有一對或全部匹配時，消息纔會被投送到對應隊列。
Fanout : 消息廣播模式。不管路由鍵或者是路由模式都會把消息發給綁定給它的全部隊列如果配置了routingkey會被忽略。
springboot集成rabbitmq