由於最近公司在使用消息中間件，在此學習並記錄一下；
1. 消息隊列使用場景：
個人認爲消息隊列的主要特點是異步處理，主要目的是減少請求響應時間和解耦。所以主要的使用場景就是將比較耗時而且不需要即時（同步）返回結果的操作作爲消息放入消息隊列。同時由於使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方並不需要彼此聯繫，也不需要受對方的影響，即解耦和。
使用場景的話，舉個例子：
假設用戶在你的軟件中註冊，服務端收到用戶的註冊請求後，它會做這些操作：
1. 校驗用戶名等信息，如果沒問題會在數據庫中添加一個用戶記錄；
2. 如果是用郵箱註冊會給你發送一封註冊成功的郵件，手機註冊則會發送一條短信；
3. 分析用戶的個人信息，以便將來向他推薦一些志同道合的人，或向那些人推薦他；
4. 發送給用戶一個包含操作指南的系統通知；
5. 等等……
但是對於用戶來說，註冊功能實際只需要第一步，只要服務端將他的賬戶信息存到數據庫中他便可以登錄上去做他想做的事情了。至於其他的事情，非要在這一次請求中全部完成麼？值得用戶浪費時間等你處理這些對他來說無關緊要的事情麼？所以實際當第一步做完後，服務端就可以把其他的操作放入對應的消息隊列中然後馬上返回用戶結果，由消息隊列異步的進行這些操作。
或者還有一種情況，同時有大量用戶註冊你的軟件，再高併發情況下注冊請求開始出現一些問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶數據記錄很快的添加到數據庫中了，但是卻卡在發郵件或分析信息時的情況，導致請求的響應時間大幅增長，甚至出現超時，這就有點不划算了。面對這種情況一般也是將這些操作放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時可以很快的完成註冊請求，不會影響用戶使用其他功能。
所以在軟件的正常功能開發中，並不需要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在可以異步處理的耗時操作，如果存在的話便可以引入消息隊列來解決。否則盲目的使用消息隊列可能會增加維護和開發的成本卻無法得到可觀的性能提升，那就得不償失了。
例子：
1. 過安檢，檢測器處理能力有限，同時這些行李又不能丟了，都得檢測。所以加了個傳送帶，慢慢過檢測器。其實這個傳送帶就是消息隊列；
2. 高併發時寫操作：
比如秒殺活動，服務器一秒能處理100個訂單，但秒殺時1秒進來10000個訂單，持續100秒，在後端能力無法增加的情況下，你可以用消息隊列將總共10000個請求壓在隊列裏，後臺consumer按原有能力處理，100秒後處理完所有請求（而不是直接宕機丟失訂單數據）；
技術都是解決問題的，消息隊列解決的是將突發大量請求轉換爲後端能承受的隊列請求。
轉載自：知乎-消息隊列
推薦：消息隊列的精髓都在這了