引入乙個故事：該故事**於：（ 祁達方的回答）
小紅是小明的姐姐。小紅希望小明多讀書，常尋找好書給小明看，之前的方式是這樣：小紅問小明什麼時候有空，把書給小明送去，並親眼監督小明讀完書才走。久而久之，兩人都覺得麻煩。
後來的方式改成了：小紅對小明說「我放到書架上的書你都要看」，然後小紅每次發現不錯的書都放到書架上，小明則看到書架上有書就拿下來看。
書架就是乙個訊息佇列，小紅是生產者，小明是消費者。
這帶來的好處有：
1.小紅想給小明書的時候，不必問小明什麼時候有空，親手把書交給他了，小紅只把書放到書架上就行了。這樣小紅小明的時間都更自由。
2.小紅相信小明的讀書自覺和讀書能力，不必親眼觀察小明的讀書過程，小紅只要做乙個放書的動作，很節省時間。
3.當明天有另乙個愛讀書的小夥伴小強加入，小紅仍舊只需要把書放到書架上，小明和小強從書架上取書即可（唔，姑且設定成多個人取一本書可以每人取走一本吧，可能是拷貝電子書或影印，暫不考慮版權問題）。
4.書架上的書放在那裡，小明閱讀速度快就早點看完，閱讀速度慢就晚點看完，沒關係，比起小紅把書遞給小明並監督小明讀完的方式，小明的壓力會小一些。
這就是訊息佇列的四大好處：
1.解耦每個成員不必受其他成員影響，可以更獨立自主，只通過乙個簡單的容器來聯絡。小紅甚至可以不知道從書架上取書的是誰，小明也可以不知道往書架上放書的人是誰，
在他們眼裡，都只有書架，沒有對方。毫無疑問，與乙個簡單的容器打交道，比與複雜的人打交道容易一萬倍，小紅小明可以自由自在地追求各自的人生。
2.提速小紅選擇相信「把書放到書架上，別的我不問」，為自己節省了大量時間。小紅很忙，只能抽出五分鐘時間，但這時間足夠把書放到書架上了。
3.廣播小紅只需要勞動一次，就可以讓多個小夥伴有書可讀，這大大地節省了她的時間，也讓新的小夥伴的加入成本很低。
4.削峰假設小明讀書很慢，如果採用小紅每給一本書都監督小明讀完的方式，小明有壓力，小紅也不耐煩。反正小紅給書的頻率也不穩定，如果今明兩天連給了五本，
之後隔三個月才又給一本，那小明只要在三個月內從書架上陸續取走五本書讀完就行了，壓力就不那麼大了。
當然，使用訊息佇列也有其成本：
1.引入複雜度毫無疑問，「書架」這東西是多出來的，需要地方放它，還需要防盜。
2.暫時的不一致性假如媽媽問小紅「小明最近讀了什麼書」，在以前的方式裡，小紅因為親眼監督小明讀完書了，可以底氣十足地告訴媽媽，
但新的方式裡，小紅回答媽媽之後會心想「小明應該會很快看完吧……」這中間存在著一段「媽媽認為小明看了某書，而小明其實還沒看」的時期，
當然，小明最終的閱讀狀態與媽媽的認知會是一致的，這就是所謂的「最終一致性」。
那麼，該使用訊息佇列的情況需要滿足什麼條件呢？
1.生產者不需要從消費者處獲得反饋引入訊息佇列之前的直接呼叫，其介面的返回值應該為空，這才讓明明下層的動作還沒做，上層卻當成動作做完了繼續往後走——即所謂非同步——成為了可能。
小紅放完書之後小明到底看了沒有，小紅根本不問，她預設他是看了，否則就只能用原來的方法監督到看完了。
2.容許短暫的不一致性媽媽可能會發現「有時候據說小明看了某書，但事實上他還沒看」，只要媽媽滿意於「反正他最後看了就行」，非同步處理就沒問題。
如果媽媽對這情況不能容忍，對小紅大發雷霆，小紅也就不敢用書架方式了。
3.確實是用了有效果即解耦、提速、廣播、削峰這些方面的收益，超過放置書架、監控書架這些成本。否則如果是盲目照搬，「聽說老趙家買了書架，咱們家也買乙個」，
買回來卻沒什麼用，只是讓步驟變多了，還不如直接把書遞給對方呢，那就不對了。
看另外乙個回答：
個人認為訊息佇列的主要特點是非同步處理，主要目的是減少請求響應時間和解耦。所以主要的使用場景就是將比較耗時而且不需要即時（同步）返回結果的操作作為訊息放入訊息佇列。同時由於使用了訊息佇列，只要保證訊息格式不變，訊息的傳送方和接收方並不需要彼此聯絡，也不需要受對方的影響，即解耦和。
使用場景：
舉個例子：假設使用者在你的軟體中註冊，服務端收到使用者的註冊請求後，它會做這些操作：
1.校驗使用者名稱等資訊，
2.如果沒問題會在資料庫中新增乙個使用者記錄如果是用郵箱註冊會給你傳送一封註冊成功的郵件，手機註冊則會傳送一條簡訊
3.分析使用者的個人資訊，以便將來向他推薦一些志同道合的人，或向那些人推薦他
4.傳送給使用者乙個包含操作指南的系統通知
5.等等……
但是對於使用者來說，註冊功能實際只需要第一步，只要服務端將他的賬戶資訊存到資料庫中他便可以登入上去做他想做的事情了。至於其他的事情，非要在這一次請求中全部完成麼？
值得使用者浪費時間等你處理這些對他來說無關緊要的事情麼？
所以實際當第一步做完後，服務端就可以把其他的操作放入對應的訊息佇列中然後馬上返回使用者結果，由訊息佇列非同步的進行這些操作。
或者還有一種情況，同時有大量使用者註冊你的軟體，再高併發情況下註冊請求開始出現一些問題，例如郵件介面承受不住，或是分析資訊時的大量計算使cpu滿載，這將會出現雖然使用者資料記錄很快的新增到資料庫中了，
但是卻卡在發郵件或分析資訊時的情況，導致請求的響應時間大幅增長，甚至出現超時，這就有點不划算了。
面對這種情況一般也是將這些操作放入訊息佇列（生產者消費者模型），訊息佇列慢慢的進行處理，同時可以很快的完成註冊請求，不會影響使用者使用其他功能。
所以在軟體的正常功能開發中，並不需要去刻意的尋找訊息佇列的使用場景，而是當出現效能瓶頸時，去檢視業務邏輯是否存在可以非同步處理的耗時操作，如果存在的話便可以引入訊息佇列來解決。
否則盲目的使用訊息佇列可能會增加維護和開發的成本卻無法得到可觀的效能提公升，那就得不償失了。
另乙個有體系的博文總結：
或者：
訊息佇列應用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。id iframe 0.05881618439392011 scrolling no 2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的...
訊息佇列應用場景
場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式 2.並行方式。1 序列方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件，再傳送註冊簡訊。以上三個任務全部完成後，返回給客戶端。2 並行方式 將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後...
訊息佇列的應用場景
參考 1 簡介 訊息佇列中介軟體是分布式系統中重要的元件，主要應用於五個場景 非同步處理 應用解耦 流量削峰 日誌處理和訊息通訊。常用的訊息佇列主要有 rabbitmq kafka activemq等 2 應用場景介紹 2.1非同步處理 場景說明 使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有...