什麼是消息隊列（Message queue）？
“Message queue”是在消息的傳輸過程中保存消息的容器，是分佈式系統中重要的組件。
簡單的使用描述：當不需要立即獲得結果，但是併發量又需要進行控制的時候，差不多就是需要使用消息隊列的時候。
當前使用較多的消息隊列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分數據庫如Redis、Mysql以及phxsql也可實現消息隊列的功能。
使用消息隊列有什麼好處？
1.提高系統響應速度
使用消息隊列，生產者一放，把消息往隊列裏一扔，就可以立馬返回，響應了用戶，無需等待處理結果。
例如：醫院體檢取化驗單，可以讓生產者訂閱，結果下來了，直接知道結果一出來，無需通知。
2.提高系統穩定性
兩個系統間緊密結合，如果有一個系統由於某些原因停止，會造成以一個系統也暫時無法使用。
例如：電商平臺，電商系統發送數據給生產系統的情況，生產系統如果由於某些原因停止服務，不使用消息隊列，電商系統發送不出去，用戶無法進行下單操作，但是如果使用消息隊列，消息隊列收到消息後，會在生產系統重新服務後，停止服務這段時間的用戶下的訂單，還是可以通過消息隊列傳輸給生產系統。
消息隊列使用場景
一、異步處理
多應用對消息隊列中同一消息進行處理，應用間併發處理消息，相比串行處理，減少處理時間；
場景說明：新用戶註冊後，需要發註冊郵件和驗證短信。
傳統的做法：
1.串行的方式
用戶註冊完成後，先發送註冊郵件，在發送驗證短信，等驗證短信發送完成後纔會將信息返回給客戶端。
2.並行方式
用戶註冊完成後，註冊右鍵及短信並行處理，等郵件和短信都處理完成後，纔會將信息返回給客戶端。
上面的兩個方式，假設每個處理時間均爲50ms,
串行需要時間：50+50+50=150ms
並行需要時間:50+50=100ms
可以看出的並行所需時間要比串行的速度提高了50ms
使用消息隊列的做法：
使用消息隊列後，我們將對發送消息及發送驗證短信異步處理。
用戶註冊完成後，將消息傳到消息隊列後，會立即將信息返回給客戶端。
二、應用解耦
多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敗；
場景說明：電商平臺，電商系統發送數據給生產系統的情況。用戶下單後訂單系統去通知生產系統。
傳統的做法：
訂單系統直接調用生產系統
如果生產系統服務停掉了，會導致用戶無法進行下單操作。
使用消息隊列的做法：
用戶下單後，訂單消息寫入了消息隊列，生產系統會通過訂閱的模式獲取訂單信息。即使生產系統服務停止了，期間的用戶下的訂單還是存在消息隊列中，等生產系統服務恢復後，生產系統從消息隊列中獲取停止服務期間的訂單信息，這樣也實現了訂單系統與生產系統之間的應用解耦。
三、流量銷鋒
應用場景：秒殺活動，一般會因爲瞬間訪問量過大，導致流量暴增，相關係統無法處理請求或服務崩潰。加入消息隊列後，系統可以在消息隊列中獲取數據，秒殺時，後入隊列的用戶無法秒殺到商品，這些請求直接拋棄，返回用戶秒殺商品已秒殺完畢等信息，這樣做了一次緩衝，極大地減少了相關係統的壓力。
![]()
消息隊列的兩種模式
一、點對點模式(queue)
一個先進先出的消息存儲區域。消息按照順序發送接收，一旦消息被消費處理，該消息將從隊列中刪除。
參與的角色：
1.消息發送者（生產者）：發送消息到消息隊列。
2.消息接收者（消費者）：從消息隊列接收消息。
3.消息隊列
流程：
一個生產者向一個特定的隊列(queue)發送消息，一個消費者從該隊列中接收消息並消費消息。消息被消費後，這個消息隊列不再存儲，所以消費者不能消費到已經消費的消息。其中，消息的生產者和消費者可以不同時處於運行狀態。
二、發佈/訂閱模式（Topic）
一種支持消息多個訂閱者的機制。
參與的角色：
1.發佈者(Publisher):發佈主題
2.訂閱者(Subscriber):訂閱主題 3.主題（Topic）
流程：
發佈者發佈一個特定的主題，並且向這個特定的主題發佈消息，訂閱者訂閱該主題後接收該主題發送過來的消息。這種模式下發布者和訂閱者彼此不知道對方，這種模式被概括爲：0個/多個消費者可以獲得消息在發佈者和訂閱者之間存在時間依賴性，即必須先訂閱，再發送消息，而後接收訂閱的消息，這個操作順序必須保證。
