什麼是訊息佇列？

上一次寫了一篇那些年，面試官問你的訊息佇列沒有深入概念，今天總結一下。

訊息佇列：也就是mq(message queue)，是基礎資料結構中「先進先出」的一種資料結構。一般用來解決應用解耦，非同步訊息，流量削鋒等問題，實現高效能，高可用，可伸縮和最終一致性架構。

指把要傳輸的資料（訊息）放在佇列中，用佇列機制來實現訊息傳遞——生產者產生訊息並把訊息放入佇列，然後由消費者去處理。消費者可以到指定佇列拉取訊息，或者訂閱相應的佇列，由mq服務端給其推送訊息。

概念：解耦：乙個業務需要多個模組共同實現，或者一條訊息有多個系統需要對應處理，只需要主業務完成以後，傳送一條mq，其餘模組消費mq訊息，即可實現業務，降低模組之間的耦合。

場景描述：系統a產生userid，現在系統b和c需要用這個userid做相關操作，過幾天說，系統b使用userid的介面不用了，讓a別去呼叫它。然後又說d系統也需要用a的userid，得呼叫介面 ......

那麼，系統a將userid寫到訊息佇列中，系統 c 和 d 從訊息佇列中拿資料。無論誰用都和系統a沒關係。且即使其他系統掛掉或者請求超時都不會影響到系統a，只和訊息佇列有關。這樣就完成了解耦。

非同步：主業務執行結束後從屬業務通過mq，非同步執行，減低業務的響應時間，提高使用者體驗。

場景描述：系統a直接呼叫系統b、c、d，有上圖得出這次請求需要50+300+300+300=950ms，系統a做的主要業務，而系統b、c、d不是。比如系統a處理的是訂單下單，而系統b是訂單下單成功了，那傳送一條簡訊告訴具體的使用者此訂單已成功，系統c和d也是處理小事。

為了提高使用者體驗和吞吐量，非同步地呼叫系統b、c、d的介面。系統a執行完了以後，將userid寫到訊息佇列中，然後直接返回(其它操作，非同步處理)。現在只需要100ms

削峰：高併發情況下，業務非同步處理，提供高峰期業務處理能力，避免系統癱瘓。

場景描述：假設每個月要搞一次大促，大促期間的併發可能會很高的，比如每秒3000個請求。假設我們現在有兩台機器處理請求，並且每台機器只能每次處理1000個請求。

多出的1000個請求可能會把整個系統搞崩了，所以我們可以寫到訊息佇列中：系統b和系統c根據自己的能夠處理的請求數去訊息佇列中拿資料，這樣即便有每秒有8000個請求，那只是把請求放在訊息佇列中，去拿訊息佇列的訊息由系統自己去控制，這樣就不會把整個系統給搞崩。

1、系統可用性降低。依賴服務也多，服務越容易掛掉。需要考慮mq癱瘓的情況。

2、系統複雜性提高。需要考慮訊息丟失、訊息重複消費、訊息傳遞的順序性。

我們將資料寫到訊息佇列上，系統b和c還沒來得及取訊息佇列的資料，就掛掉了。如果沒有做任何的措施，我們的資料就丟了。

3、業務一致性。主業務和從屬業務一致性的處理。