使用場景的話，舉個例子：
假設用戶在妳的軟件中註冊，服務端收到用戶的註冊請求後，它會做這些操作：
校驗用戶名等信息，如果沒問題會在數據庫中添加壹個用戶記錄
如果是用郵箱註冊會給妳發送壹封註冊成功的郵件，手機註冊則會發送壹條短信
分析用戶的個人信息，以便將來向他推薦壹些誌同道合的人，或向那些人推薦他
發送給用戶壹個包含操作指南的系統通知
等等……
但是對於用戶來說，註冊功能實際只需要第壹步，只要服務端將他的賬戶信息存到數據庫中他便可以登錄上去做他想做的事情了。至於其他的事情，非要在這壹次請求中全部完成麽？值得用戶浪費時間等妳處理這些對他來說無關緊要的事情麽？所以實際當第壹步做完後，服務端就可以把其他的操作放入對應的消息隊列中然後馬上返回用戶結果，由消息隊列異步的進行這些操作。
或者還有壹種情況，同時有大量用戶註冊妳的軟件，再高並發情況下註冊請求開始出現壹些問題，例如郵件接口承受不住，或是分析信息時的大量計算使cpu滿載，這將會出現雖然用戶數據記錄很快的添加到數據庫中了，但是卻卡在發郵件或分析信息時的情況，導致請求的響應時間大幅增長，甚至出現超時，這就有點不劃算了。面對這種情況壹般也是將這些操作放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時可以很快的完成註冊請求，不會影響用戶使用其他功能。