今年疫情嚴峻，希望早日控制住，有不少的朋友都打算年後找份新的工作，正好趁著這個時候好好學習，提升下自己。今天我們來聊一聊消息隊列的作用。消息隊列，相信大家都不陌生，Kafka、RMQ都是大家常用的隊列，也是程式設計師面試中的一個常見的題目。
進行削峰，減少並發
數據在後臺各個系統中流轉就跟流水線上的工人一樣，如果前面的工人幹得非常快，那麼工作就會不停地堆積，很多零件就堆積著等著下面的工人解決。如果請求一直堆積著得不到處理，用戶就只能夠一直等待，會有不好的體驗，同時，因為任務堆積，總是需要佔用內存、連接數等資源，就容易引發服務雪崩。
所以，對一些實時性要求不高的請求，我們通常可以採用異步進行削峰。一個常見的例子，在電商系統中，當用戶下單並完成支付的時候，我們通常會去通知商家的後臺，告訴他們可以發貨了。但是不同的商家的技術良莠不齊，有些速度真是跟蝸牛一樣，這個時候我們這可以採用異步的方式，使用消息隊列，慢慢地進行通知。
系統解耦
當我們開始開發一個系統的時候，邏輯總是比較清晰跟簡單，隨著需求的迭代，我們會發現系統越來越複雜，如果開發的程式設計師能力不足的話，我們會發現系統會越來越混亂，最後甚至出現一個方法幾千行代碼的情況，那麼對於一個越來越複雜地系統，我們怎麼進行系統的解耦呢?
在一個電商系統中，當我們完成一次交易的時候，遠遠沒有想像中那麼地簡單，我們通常需要通知倉庫或者通知商家，讓他們接受訂單，儘快發貨。同時，我們可能要通知積分系統，給用戶下發一定的交易積分。可能這個用戶是通過分銷過來購買的，需要通知分銷系統，創建分銷訂單，以便後面的結算。一次簡單的交易過後，我們可能要同時數十個系統，像阿里巴巴的天貓淘寶，可能完成一次交易，甚至要通知100個系統。如果我們在我們的交易流程裡面，逐個系統逐漸通知，那麼必然會帶來系統緩慢的問題，所以我們可以使用消息隊列，每次交易成功後發布一條消息，讓其他系統去訂閱這條消息。就可以做到系統的解耦了。
延遲處理
在程序設計中，延遲任務也是常有的事情。例如用戶創建一次訂單之後，可能沒有支付。我們可以在創建訂單25分鐘之後去提醒用戶，告訴他有筆訂單未支付，萬一用戶支付了。豈不是美滋滋。一些消息隊列提供了延遲隊列功能，例如RabbitMQ，我們可以利用其延遲的特性，非常簡單地實現這個功能。
當然，我們也可以使用其他方法，例如每一分鐘掃描一次資料庫等等。歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。