消息隊列

　　最近幾年，團購、秒殺等購物應用異常火爆，既然購物，就涉及數據庫操做。那麼這麼大的冰法是怎麼處理的？不會吧數據庫搞垮嗎？答案是確定的。一個解決辦法就是把HTTP請求放入內存中的高速隊列，而後對隊列裏的數據按必定的規則進行分流處理，這就是HTTP請求隊列。

　　好比，微博和SNS一般擁有上億的受衆數量，一個明星或者公衆人物可能有幾千萬粉絲，若是一個公衆物發了一條微博，那麼就得推送到全部關注者那裏（有推策略、拉策略、隨機策略、優先策略等），這時就必須用到隊列了。

　　隨着網站用戶數量的增長，若在前端頁面直接寫入大量數據，會延長用戶的等待時間，在多併發的狀況下，頁面效率低、壓力集中。爲了解決上述問題，考慮使用數據的異步處理。而消息隊列背後實質就是一種「異步處理」的思想。

 

一、隊列（queue）和棧同樣，是一種線性表結構，不過隊列是一種先進先出(FIFO)的數據結構。隊列只容許在後端進行插入操做，在前端進行刪除操做。

二、咱們發微博時，其實咱們能夠注意到，好友動態自己沒必要具備十分高的實時要求。因此，咱們採用異步的推，把動態推給好友，而不是好友主動拉取。

三、「消息隊列」的原理：

　　　　」消息隊列「是在消息的傳輸過程當中保存消息的容器。消息隊列管理器在將消息從它的源中繼到它的目標時充當中間人的角色。隊列主要提供路由並保證消息的傳遞；若是發送消息時接收者不可用，消息隊列會保留信息，直到成功傳遞。利用消息隊列能夠很好地異步處理數據傳送和存儲，當頻繁地向數據庫插入數據時，就可採用消息隊列異步插入。另外，可將比較慢的處理邏輯、有併發數量限制的處理邏輯，經過消息隊列放在後臺處理，例如視頻轉發、發送手機短信等。

　　　　　　注意：在隊列中存儲的是消息，而不是實際要分發和處理的數據。秒殺隊列中存儲的僅僅是一個HTTP請求，SNS隊列中存數的僅僅是一個製造出來的動態，而不是全部要分發的動態。動態的分發不是消息隊列所負責，其由另外一個程序處理

四、消息隊列須要一個輪詢調度的程序，經過定製的調度把原先一瞬間可能發送的成千上萬動態分發插入的操做延遲，而且是定製分發量，把高峯期的負載分一部分到低谷時間進行處理，這樣能減小不少負擔。