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

[[345196]]

流量削峰

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

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

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

系統解耦

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

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

消息隊列，是一種更簡單又更可靠的方法。當我們成功完成一次交易行為之后，我們生產一條消息，所有的業務方都來消費這條消息，由業務方自己來保證成功消費。這樣子，交易系統就不用關心交易行為的后續動作，大大減少了交易系統的復雜性。

延遲與異步

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

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

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

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