MQ訊息佇列

1. 解耦

系統a將userid寫到訊息佇列中，系統c和系統d從訊息佇列中拿資料。這樣有什麼好處？

系統a只負責把資料寫到佇列中，誰想要或不想要這個資料(訊息)，系統a一點都不關心。

即便現在系統d不想要userid這個資料了，系統b又突然想要userid這個資料了，都跟系統a無關，系統a一點**都不用改。

系統d拿userid不再經過系統a，而是從訊息佇列裡邊拿。系統d即便掛了或者請求超時，都跟系統a無關，只跟訊息佇列有關。

這樣一來，系統a與系統b、c、d都解耦了。

2. 非同步

假設系統a運算出userid具體的值需要50ms，呼叫系統b的介面需要300ms，呼叫系統c的介面需要300ms，呼叫系統d的介面需要300ms。那麼這次請求就需要50+300+300+300=950ms

並且我們得知，系統a做的是主要的業務，而系統b、c、d是非主要的業務。比如系統a處理的是訂單下單，而系統b是訂單下單成功了，那傳送一條簡訊告訴具體的使用者此訂單已成功，而系統c和系統d也是處理一些小事而已。

那麼此時，為了提高使用者體驗和吞吐量，其實可以非同步地呼叫系統b、c、d的介面。所以，我們可以弄成是這樣的：

系統a執行完了以後，將userid寫到訊息佇列中，然後就直接返回了(至於其他的操作，則非同步處理)。

本來整個請求需要用950ms(同步)

現在將呼叫其他系統介面非同步化，只需要100ms(非同步)

3. 削峰/限流

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

那多出來的1000個請求，可能就把我們整個系統給搞崩了…所以，有一種辦法，我們可以寫到訊息佇列中：

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

1高可用

無論是我們使用訊息佇列來做解耦、非同步還是削峰，訊息佇列肯定不能是單機的。試著想一下，如果是單機的訊息佇列，萬一這台機器掛了，那我們整個系統幾乎就是不可用了。

所以，當我們專案中使用訊息佇列，都是得集群/分布式的。要做集群/分布式就必然希望該訊息佇列能夠提供現成的支援，而不是自己寫**手動去實現。

2 資料丟失問題

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

學過redis的都知道，redis可以將資料持久化磁碟上，萬一redis掛了，還能從磁碟從將資料恢復過來。同樣地，訊息佇列中的資料也需要存在別的地方，這樣才盡可能減少資料的丟失。

那存在哪呢？

磁碟？資料庫？

redis？

分布式檔案系統？

同步儲存還是非同步儲存？

3消費者怎麼得到訊息佇列的資料？

消費者怎麼從訊息佇列裡邊得到資料？有兩種辦法：

生產者將資料放到訊息佇列中，訊息佇列有資料了，主動叫消費者去拿(俗稱push)

消費者不斷去輪訓訊息佇列，看看有沒有新的資料，如果有就消費(俗稱pull)

4其他

除了這些，我們在使用的時候還得考慮各種的問題：

訊息重複消費了怎麼辦啊？

我想保證訊息是絕對有順序的怎麼做？

………雖然訊息佇列給我們帶來了那麼多的好處，但同時我們發現引入訊息佇列也會提高系統的複雜性。市面上現在已經有不少訊息佇列輪子了，每種訊息佇列都有自己的特點，選取哪種mq還得好好斟酌。

參考資料：