今年疫情嚴峻，希望早日控制住，有不少的朋友都打算年后找份新的工作，正好趁著這個時候好好學習，提升下自己。今天我們來聊一聊消息隊列的作用。消息隊列，相信大家都不陌生，Kafka、RMQ都是大家常用的隊列，也是程序員面試中的一個常見的題目。

[[314087]]

進行削峰，減少并發

數據在后臺各個系統中流轉就跟流水線上的工人一樣，如果前面的工人干得非常快，那么工作就會不停地堆積，很多零件就堆積著等著下面的工人解決。如果請求一直堆積著得不到處理，用戶就只能夠一直等待，會有不好的體驗，同時，因為任務堆積，總是需要占用內存、連接數等資源，就容易引發服務雪崩。所以，對一些實時性要求不高的請求，我們通常可以采用異步進行削峰。一個常見的例子，在電商系統中，當用戶下單并完成支付的時候，我們通常會去通知商家的后臺，告訴他們可以發貨了。但是不同的商家的技術良莠不齊，有些速度真是跟蝸牛一樣，這個時候我們這可以采用異步的方式，使用消息隊列，慢慢地進行通知。

系統解耦

當我們開始開發一個系統的時候，邏輯總是比較清晰跟簡單，隨著需求的迭代，我們會發現系統越來越復雜，如果開發的程序員能力不足的話，我們會發現系統會越來越混亂，最后甚至出現一個方法幾千行代碼的情況，那么對于一個越來越復雜地系統，我們怎么進行系統的解耦呢?

在一個電商系統中，當我們完成一次交易的時候，遠遠沒有想象中那么地簡單，我們通常需要通知倉庫或者通知商家，讓他們接受訂單，盡快發貨。同時，我們可能要通知積分系統，給用戶下發一定的交易積分。可能這個用戶是通過分銷過來購買的，需要通知分銷系統，創建分銷訂單，以便后面的結算。一次簡單的交易過后，我們可能要同時數十個系統，像阿里巴巴的天貓淘寶，可能完成一次交易，甚至要通知100個系統。如果我們在我們的交易流程里面，逐個系統逐漸通知，那么必然會帶來系統緩慢的問題，所以我們可以使用消息隊列，每次交易成功后發布一條消息，讓其他系統去訂閱這條消息。就可以做到系統的解耦了。

延遲處理

在程序設計中，延遲任務也是常有的事情。例如用戶創建一次訂單之后，可能沒有支付。我們可以在創建訂單25分鐘之后去提醒用戶，告訴他有筆訂單未支付，萬一用戶支付了。豈不是美滋滋。一些消息隊列提供了延遲隊列功能，例如RabbitMQ，我們可以利用其延遲的特性，非常簡單地實現這個功能。當然，我們也可以使用其他方法，例如每一分鐘掃描一次數據庫等等。歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。