消息隊列在后臺技術(shù)棧中，占有舉足輕重的作用，接下來的一段時間，我們會系統(tǒng)的講一講消息隊列。 今天我們主要來講一講消息隊列的作用。

[[345196]]

流量削峰

消息隊列，其實并不是什么深奧的東西，類似這次我們的國慶出行，許多的景區(qū)都會出現(xiàn)人滿為患，到處都是人從眾的現(xiàn)象，這個時候，景區(qū)是怎么解決問題的呢?通常就是排隊限流了，在檢票處設(shè)一個等待區(qū)域，如果景區(qū)里面的人太多，那么就在售票處設(shè)立一個等待區(qū)，讓游客進(jìn)行排隊， 等景區(qū)出來一些游客后，再放一批游客進(jìn)去。

現(xiàn)實的生產(chǎn)環(huán)境也是如此，在生產(chǎn)環(huán)境中，每個系統(tǒng)的容量是不一樣的，核心系統(tǒng)或者簡單的系統(tǒng)吞吐量往往比較大，非核心系統(tǒng)與復(fù)雜系統(tǒng)往往吞吐量比較低。舉個例子，在電商系統(tǒng)中，我們經(jīng)常要對用戶行為進(jìn)行數(shù)據(jù)上報，相對于用戶瀏覽、交易等行為，數(shù)據(jù)上報顯得并不那么重要，所以支撐數(shù)據(jù)上報的系統(tǒng)性能往往是不如核心功能的。

在一些流量的高峰，例如雙十一大促，我們一般不會對這種上報系統(tǒng)進(jìn)行擴容，這個時候，同步的進(jìn)行數(shù)據(jù)上報容易引發(fā)雪崩，應(yīng)對這種情況，我們可以把用戶行為數(shù)據(jù)的寫入放入異步隊列，可以根據(jù)數(shù)據(jù)的寫入速度進(jìn)行消費，從而保證系統(tǒng)的魯棒性。

系統(tǒng)解耦

當(dāng)我們開始開發(fā)一個系統(tǒng)的時候，邏輯總是比較清晰跟簡單，隨著需求的迭代，系統(tǒng)會變得越來越復(fù)雜，舉個簡單的例子，原先我們進(jìn)行一次交易的時候，可能交易系統(tǒng)可能只是踐行簡單的庫存扣減，然后寫入訂單。隨著功能的迭代，我們需要通知廣告系統(tǒng)、第三方的賣家的話、需要通知商家系統(tǒng)等等，像阿里巴巴，每發(fā)生一次簡單的交易行為之后，可能需要通知數(shù)十個不同的業(yè)務(wù)方進(jìn)行處理。

這些增加的邏輯，假如我們都做在交易系統(tǒng)的話，就會發(fā)現(xiàn)交易系統(tǒng)會變得越來越臃腫不堪，而且會難以保證數(shù)據(jù)的一致性。假如成單之后，通知廣告系統(tǒng)失敗了(例如網(wǎng)絡(luò)波動)，那么，這次交易行為是否還要進(jìn)行下去呢，通知廣告系統(tǒng)這種可能失敗了就算了，要是通知商家系統(tǒng)失敗了呢?數(shù)據(jù)不一致可能會給公司帶來投訴與資損，后期開發(fā)要花大量的時間進(jìn)行數(shù)據(jù)修復(fù)。

消息隊列，是一種更簡單又更可靠的方法。當(dāng)我們成功完成一次交易行為之后，我們生產(chǎn)一條消息，所有的業(yè)務(wù)方都來消費這條消息，由業(yè)務(wù)方自己來保證成功消費。這樣子，交易系統(tǒng)就不用關(guān)心交易行為的后續(xù)動作，大大減少了交易系統(tǒng)的復(fù)雜性。

延遲與異步

這樣的場景在電商系統(tǒng)是非常常見的，用戶創(chuàng)建一次訂單之后，可能沒有支付，我們可以在創(chuàng)建訂單25分鐘之后去提醒用戶，告訴他有筆訂單未支付，從而提高轉(zhuǎn)化率。假如讓你來實現(xiàn)這個功能，那么你要怎么做呢?

我們可以使用一個定時任務(wù)，每分鐘都去掃描數(shù)據(jù)庫，把未支付的訂單掃出來，然后通知用戶進(jìn)行支付。這也是一個不錯的方法，但是，一個可靠的定時任務(wù)的難點這里就不進(jìn)行贅述了，我們今天來介紹另外一個方法，那就是消息隊列。

一些消息隊列提供了延遲隊列功能，例如RabbitMQ，我們可以利用其延遲的特性，非常簡單地實現(xiàn)這個功能。當(dāng)用戶下單的時候，我們發(fā)布一個延遲消息，等到消費的時候，再去查詢訂單的狀態(tài)，后面，我們會單獨講消息隊列延遲是如何保證可靠性的。

今天我們主要講了消息隊列的三個作用，接下來我們會介紹幾個常見的消息隊列以及他們的特點，如果你有興趣，歡迎關(guān)注我，我們一起學(xué)習(xí)，一起進(jìn)步。