第一次聽到“消息隊列”這個詞時，不知你是不是和我反應一樣，感覺很高階很厲害的樣子，其實當我們瞭解了消息隊列之後，發現它與普通的技術類似，當我們熟悉之後，也能很快地上手並使用。
我們本課時的面試題是，消息隊列的使用場景有哪些？如何手動實現一個消息隊列和延遲消息隊列？
典型回答
消息隊列的使用場景有很多，最常見的使用場景有以下幾個。
1.商品秒殺
比如，我們在做秒殺活動時，會發生短時間內出現爆發式的用戶請求，如果不採取相關的措施，會導致服務器忙不過來，響應超時的問題，輕則會導致服務假死，重則會讓服務器直接宕機，給用戶帶來的體驗也非常不好。如果這個時候加上了消息隊列，服務器接收到用戶的所有請求後，先把這些請求全部寫入到消息隊列中再排隊處理，這樣就不會導致同時處理多個請求的情況；如果消息隊列長度超過可以承載的最大數量，那麼我們可以拋棄當前用戶的請求，通知前臺用戶“頁面出錯啦，請重新刷新”等提示，這樣就會有更好的交互體驗。
2.系統解耦
使用了消息隊列之後，我們可以把系統的業務功能模塊化，實現系統的解耦。例如，在沒有使用消息隊列之前，當前臺用戶完善了個人信息之後，首先我們需要更新用戶的資料，再添加一條用戶信息修改日誌。但突然有一天產品經理提了一個需求，在前臺用戶信息更新之後，需要給此用戶的增加一定的積分獎勵，然後沒過幾天產品經理又提了一個需求，在前臺用戶信息更新之後，不但要增加積分獎勵，還要增加用戶的經驗值，但沒過幾天產品經理的需求又變了，他要求完善資料無需增加用戶的積分了，這樣反反覆覆、來來回回的折騰，我想研發的同學一定受不了，但這是互聯網公司的常態，那我們有沒有一勞永逸的辦法呢？
沒錯，這個時候我們想到了使用消息隊列來實現系統的解耦，每個功能的實現獨立開，只需要一個訂閱或者取消訂閱的開關就可以了，當需要增加功能時，只需要打開訂閱“用戶信息完善”的隊列就行，如果過兩天不用了，再把訂閱的開關關掉就行了，這樣我們就不用來來回回的改業務代碼了，也就輕鬆的實現了系統模塊間的解耦。
3.日誌記錄
我們大部分的日誌記錄行爲其實是和前臺用戶操作的主業務沒有直接關係的，只是我們