訊息佇列也算是當前面試中必問的乙個知識點了。而且，如果你說不會，好像別人就抓住了你的短板一樣。
現在到哪都一堆人，**和當年差的太多了。今天，為了不適尷尬，能和面試官聊的更嗨，我給你說說，訊息佇列的 3 大使用場景。
當然，訊息佇列絕對不限於這 3 個場景。我概括的還是比較籠統的，抓住主要的場景，就是抓住了面試的機會。
1、支援非同步處理的服務。
這個是訊息佇列使用的一大場景。比如，在電商專案中，我們的下單，出庫，扣減庫存，簡訊通知，報表統計等都是可以支援和使用訊息佇列的。
在這些場景中，有了訊息佇列後，對使用者的體驗也很高。比如，如果不使用訊息佇列，當我們支付成功後，需要進行出庫，就需要在支付成功後，直接發起出庫請求到閘道器，或者通過定時任務去通知出庫。而有了，訊息佇列後，就可以支援非同步處理了。
再比如，我們有些訂單是，下單減庫存，有些是支付減庫存。有了訊息佇列，對於訂單服務和庫存服務就能更好的進行非同步處理了。而且，伴隨著乙個訂單的狀態的變化，可以針對不同狀態的訂單形成很多的訂閱。
可能還有人問，只非同步處理，也顯示不出來訊息佇列的優勢吧。那我們來看看第二大使用場景。
2、限流，流量或流速控制。
和現實中的排隊一樣，訊息佇列還能控制著流速。類似的就是，當生產者和消費者不能很快進行消費的時候，就可以利用訊息佇列進行堆積。
再比如，在秒殺場景中，1000 個人，可能會有 1000 個設計。但是，利用訊息佇列來限制併發也是一種不錯的辦法。
3、降低**的耦合度
說一千道一萬，我也可以不使用訊息佇列來實現業務功能。但是，能否在實現功能的同時做到解耦。這也是架構設計中的乙個關鍵，耦合度越高，越難擴充套件。
而且，解耦之後，針對不同的主題，你隨時可以去形成訂閱。尤其是對於快速發展的系統，變更是常有的事，當我們能做到解耦後，上游系統和下游系統之間的變更，依程度就不是那麼高了。架構的平衡藝術就發揮的淋淋盡致。
訊息佇列使用場景
1 非同步處理 減少等待時間，更快的返回處理結果，提高系統效能以及更好的使用者體驗。fe 在乙個秒殺系統中，可能需要如下幾步 風險控制，鎖定庫存，生成訂單，訊息通知以及統計資料，在未優化的情況下，使用者請求到達閘道器後進入服務端要至少 經歷這五個步驟，但是對於秒殺系統而言關鍵的步驟在於風險控制和鎖定...
訊息佇列的使用場景
知乎 假設使用者在你的軟體中註冊，服務端收到使用者的註冊請求後，它會做這些操作 校驗使用者名稱等資訊，如果沒問題會在資料庫中新增乙個使用者記錄 如果是用郵箱註冊會給你傳送一封註冊成功的郵件，手機註冊則會傳送一條簡訊 分析使用者的個人資訊，以便將來向他推薦一些志同道合的人，或向那些人推薦他 傳送給使用...
訊息佇列的使用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的差別是，並行的方式可以提高處理的時間。假設三個業務節點每個使用50毫秒鐘，不考慮網路等...