最近在研究網站的異步消息隊列模型，漸漸有了一些心得，下面就說說我個人對於消息隊列的理解。
什么是消息隊列？
所謂消息隊列，就是一個以隊列數據結構為基礎的一個實體，這個實體是真實存在的，比如程序中的數組，數據庫中的表，或者redis等等，都可以。
首先我們說說為什么要使用隊列，什么情況下才會使用隊列？
我的理解是，那些實時性要求不高，且比較耗時的任務，是隊列的最佳應用場景。比如說我在某網站注冊一個賬號，當我的信息入庫注冊成功后，網站需要發送一封激活郵件，讓我激活賬號，而這個發郵件的操作並不是需要實時響應的，沒有必要卡在那個注冊界面，等待郵件發送成功，再說發送郵件本來就是一個耗時的操作（需要調用第三方smtp服務器），此時，選擇消息隊列去處理。注冊完成，我只要向隊列投遞一個消息，消息的內容中包含我要發送郵件的一些設置，以及發送時間，重試次數等消息屬性。這里的投遞操作（可以是入庫，寫入緩存等）是要消息進入一個實體的隊列。其中應該有一進程（消費者）一直在后台運行，他不斷的去輪訓隊列中的消息（按照時間正序，隊列是先進先出），看有沒有達到執行條件的，如果有就取出一條，根據消息配置，執行任務，如果成功，則銷毀這條消息，繼續輪訓，如果失敗，則重試，知道達到重試次數。這時用戶已經收到注冊成功的提示，但是已經去做其他事了，郵件也來了，用戶點擊郵件，注冊成功。這就是消息隊列的一個典型應用。
再說一個場景，點贊，這個在高並發的情況下，很容易造成數據庫連接數占滿，到時整個網站響應緩慢，才是就是想到要解決數據庫的壓力問題，一般就是兩種方案，一是提高數據庫本身的能力（如增加連接數，讀寫分離等），但是數據庫總是有極限的，到達了極限是沒有辦法在提升了的，此時就要考慮第二種方案，釋放數據庫的壓力，將壓力轉移到緩存里面。就拿實際的點贊來說吧，用戶的點贊請求到來，我只是將點贊請求投遞到消息隊列里面，后續的點贊請求可以將消息合並，即只更新點贊數，不產生新的任務，此時有個進行再不斷的輪訓消息隊列，將點贊消息消耗，並將值更新到數據庫里面，這樣就有效的降低了數據庫的壓力，因為在緩存層將數個數據庫更新請求合並成一個，大大提高了效率，降低了負載。