場景說明：使用者下單後，訂單需要通知庫存系統。傳統的做法是訂單系統直接呼叫庫存系統的介面。
傳統模式的缺點：
1.假如庫存系統無法訪問，則訂單系統訪問庫存系統失敗，從而導致訂單失敗
2.訂單系統與庫存系統耦合
引入訊息佇列
訂單系統：使用者下單後，訂單系統完成持久化處理，將訊息寫入訊息佇列，返回使用者下單成功
庫存系統：訂閱下單的訊息，採用拉去/推送的方式獲取下單資訊。庫存系統根據下單資訊，進行庫存操作
假如：在下單時，庫存系統不能正常使用，也不影響正常下單，因為下單後，訂單系統寫入訊息佇列就不再關心後續其他操作，實現訂單系統與庫存系統的解耦
基於訊息的模型，關係的是通知，而非處理。
簡訊、郵件通知、快取書信等操作使用訊息佇列進行通知。
場景說明：使用者註冊後，需要傳送註冊郵件和註冊簡訊。傳統的做法有兩種：序列和並行
1、穿行方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件，再傳送註冊簡訊。完成以上三個任務後，返回給客戶端。
2、並行方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊，完成以上三個任務後，返回給客戶端。並行方式可以提高處理時間，提公升效率。
3、引入訊息佇列，將不是必須的業務邏輯做非同步處理。使用者註冊資訊寫入資料庫成功後再，寫入訊息到訊息佇列，傳送郵件和短息的服務從訊息佇列獲取到訊息後非同步完成短息和郵件的傳送。
流量削峰也是訊息佇列的常用場景，一般再秒殺或者團搶活動中廣泛使用
應用場景：系統其他時間a系統每秒請求量就100個，系統可以穩定執行。系統每天晚間八點有秒殺活動，每秒併發請求量增至1萬條，但是系統最大的處理能力只能每秒處理1000個請求，於是系統崩潰，伺服器宕機。
之前架構：大量使用者（100萬使用者）通過瀏覽器在晚上八點高峰期同時參與秒殺活動。大量的請求湧入我們的系統中，高峰期達到每秒鐘5000個請求，大量的請求打到mysql上，每秒鐘預計執行3000條sql。但是一般的mysql每秒鐘扛住2000個請求就不錯了，如果達到3000個請求的話可能mysql直接就癱瘓了，從而系統無法被使用。但是高峰期過了之後，就成了低峰期，可能也就1萬使用者訪問系統，每秒的請求數量也就50個左右，整個系統幾乎沒有任何壓力。
引入mq：100萬使用者在高峰期的時候，每秒請求有5000個請求左右，將這5000請求寫入mq裡面，系統a每秒最多只能處理2000請求，因為mysql每秒只能處理2000個請求。系統a從mq中慢慢拉取請求，每秒就拉取2000個請求，不要超過自己每秒能處理的請求數量即可。mq，每秒5000個請求進來，結果只有2000個請求出去，所以在秒殺期間（將近一小時）可能會有幾十萬或者幾百萬的請求積壓在mq中。這個短暫的高峰期積壓是沒問題的，因為高峰期過了之後，每秒就只有50個請求進入mq了，但是系統還是按照每秒2000個請求的速度在處理，所以說，只要高峰期一過，系統就會快速將積壓的訊息消費掉。我們在此計算一下，每秒在mq積壓3000條訊息，1分鐘會積壓18萬，1小時積壓1000萬條訊息，高峰期過後，1個多小時就可以將積壓的1000萬訊息消費掉。
訊息佇列應用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。id iframe 0.05881618439392011 scrolling no 2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的...
訊息佇列應用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。1 序列方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件，再傳送註冊簡訊。以上三個任務全部完成後，返回給客戶端。2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後...
訊息佇列的應用場景
參考 1 簡介 訊息佇列中介軟體是分布式系統中重要的元件，主要應用於五個場景 非同步處理 應用解耦 流量削峰 日誌處理和訊息通訊。常用的訊息佇列主要有 rabbitmq kafka activemq等 2 應用場景介紹 2.1非同步處理 場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有...