淺談異步消息隊列模型

最近在研究網站的異步消息隊列模型，漸漸有了一些心得，下面就說說我我的對於消息隊列的理解。

什麼是消息隊列？

所謂消息隊列，就是一個以隊列數據結構爲基礎的一個實體，這個實體是真實存在的，好比程序中的數組，數據庫中的表，或者redis等等，均可以。

首先咱們說說爲何要使用隊列，什麼狀況下才會使用隊列？

個人理解是，那些實時性要求不高，且比較耗時的任務，是隊列的最佳應用場景。好比說我在某網站註冊一個帳號，當個人信息入庫註冊成功後，網站須要發送一封激活郵件，讓我激活帳號，而這個發郵件的操做並非須要實時響應的，沒有必要卡在那個註冊界面，等待郵件發送成功，再說發送郵件原本就是一個耗時的操做（須要調用第三方smtp服務器），此時，選擇消息隊列去處理。註冊完成，我只要向隊列投遞一個消息，消息的內容中包含我要發送郵件的一些設置，以及發送時間，重試次數等消息屬性。這裏的投遞操做（能夠是入庫，寫入緩存等）是要消息進入一個實體的隊列。其中應該有一進程（消費者）一直在後臺運行，他不斷的去輪訓隊列中的消息（按照時間正序，隊列是先進先出），看有沒有達到執行條件的，若是有就取出一條，根據消息配置，執行任務，若是成功，則銷燬這條消息，繼續輪訓，若是失敗，則重試，知道達到重試次數。這時用戶已經收到註冊成功的提示，可是已經去作其餘事了，郵件也來了，用戶點擊郵件，註冊成功。這就是消息隊列的一個典型應用。
再說一個場景，點贊，這個在高併發的狀況下，很容易形成數據庫鏈接數佔滿，到時整個網站響應緩慢，纔是就是想到要解決數據庫的壓力問題，通常就是兩種方案，一是提升數據庫自己的能力（如增長鏈接數，讀寫分離等），可是數據庫老是有極限的，到達了極限是沒有辦法在提高了的，此時就要考慮第二種方案，釋放數據庫的壓力，將壓力轉移到緩存裏面。就拿實際的點贊來講吧，用戶的點贊請求到來，我只是將點贊請求投遞到消息隊列裏面，後續的點贊請求能夠將消息合併，即只更新點贊數，不產生新的任務，此時有個進行再不斷的輪訓消息隊列，將點贊消息消耗，並將值更新到數據庫裏面，這樣就有效的下降了數據庫的壓力，由於在緩存層將數個數據庫更新請求合併成一個，大大提升了效率，下降了負載。