13.app後端為什麼要用到訊息佇列，13.app後端訊息佇列

13.app後端為什麼要用到訊息佇列，13.app後端訊息佇列
       很多沒有實際項目經驗的小夥伴，對訊息佇列系統非常陌生，看著很多架構的介紹中，都提到訊息佇列。但是，不知道為什麼要用訊息佇列？什麼是訊息佇列？常見的訊息佇列產品有哪些？


　　通過閱讀本文，幫你解開以上的疑惑。


1. 為什麼要用訊息佇列？

　　假設一個老大，接到一個任務要處理完。在處理這個任務時，把這個任務分解為幾個小任務，只要分別完成了這幾個小任務，整個任務也就完成了。


　　做到某個小任務時，發現這個小任務需要花很多時間完成，而且這個小任務遲點完成也不影響整個任務的完成進度。於是，老大把這個小任務交個一個小弟去做，自己去接著完成其他的任務。


　　在上面的例子中，老大就是後台系統，小弟就是訊息佇列系統，當後台系統發現完成某些小任務需要花很多時間，而且遲點完成也不影響整個任務的，就會把這些小任務交給訊息佇列系統。


　　在實際的app後端中，發送郵件，傳送簡訊，推送等這些任務，都非常適合在訊息佇列系統中做的。大家想想，這些任務是不是都需要花比較多的時間，而且遲點完成也不影響的。把這些任務放在隊列中，可加快請求的回應時間。


2. 訊息佇列是怎麼工作？

　　訊息佇列系統，一般都包含3個角色：佇列服務端，隊列的生產者，隊列的消費者。


　　訊息佇列系統類別似於這個情境：有一條資訊傳送帶不停地運轉。在傳送帶的起點，工人a不斷地把資訊放在一個盒子，把盒子放到傳送帶上，盒子被傳送帶傳送到終點。在終點上，工人b把盒子上的資訊取出來，進行處理。


　　在上面的情境中，不停運轉的傳送帶就是佇列服務端，在傳送帶起點不斷放盒子的工人a就是隊列的生產者，在傳送帶終點不斷取盒子的工人b就是隊列的消費者。


　　訊息佇列的服務端，現在有大量的開源的應用，例如RabbitMQ ，ZeroMQ ，redis等。


　　隊列的生產者和服務者，是針對訊息佇列服務端開發的用戶端，例如，RabbitMQ就有針對java，php等語言開發的用戶端。


　　例如，在app後端中，用代碼調用 java用戶端，把要發送的簡訊資訊放在ZeroMQ中，這裡java用戶端是充當隊列的生產者。


　　寫一個守護進程，在守護進程中，通過代碼調用 java用戶端把要發送的簡訊資訊不斷地從ZeroMQ取出來，然後發送出去。


3. 常見的一些訊息佇列產品

　　RabbitMQ:


　　是使用Erlang編寫的一個開源的訊息佇列，本身支援很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人(Broker)構架，這意味著訊息在發送給用戶端時先在中心隊列排隊。對路由(Routing)，負載平衡(Load balance)或者資料持久化都有很好的支援。


　　同時，RabbitMQ內建了一個web監控介面，可方便監控隊列的情況。


　　Redis：


　　雖然是一個key-value系統，但自身也支援隊列這種資料結構，可看做是一個輕量級的訊息佇列系統。


　　在app後端架構中，redis是被廣泛使用，如果同時把它作為訊息佇列使用，就減少了營運上的成本。


　　ZeroMq：


　　號稱最快的訊息佇列系統，尤其針對大輸送量的需求情境。


　　ActiveMQ：

　　是Apache下的一個子項目。 類似於ZeroMQ，它能夠以代理人和點對點的技術實現隊列。

---------------------------------------------------------------------------------------------------------------------------

開啟連結  app後端系列文章總目錄 總目錄 ，能查看本人發表過的所有原創“app後端”文章。

【作者】曾健生
【QQ】190678908
【qq群】254659220 
【公眾號】 appbackend
【新浪微博】 @newjueqi
【部落格】http://blog.csdn.net/newjueqi