web應用中為什麼會需要訊息佇列？主要原因是由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達mysql，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，我們可以非同步處理請求，從而緩解系統的壓力。在web2.0的時代，高併發的情況越來越常見，從而使訊息佇列有成為居家必備的趨勢，相應的也湧現出了很多實現方案，像twitter以前就使用rabbitmq實現訊息佇列服務，現在又轉而使用kestrel來實現訊息佇列服務，此外還有很多其他的選擇，比如說：activemq，zeromq等。
上述訊息佇列的軟體中，大多為了實現amqp，stomp，xmpp之類的協議，變得極其重量級，但在很多web應用中的實際情況是：我們只是想找到乙個緩解高併發請求的解決方案，不需要雜七雜八的功能，乙個輕量級的訊息佇列實現方式才是我們真正需要的。
第一感覺是能不能使用memcached來實現訊息佇列？稍加考慮後就會發現它不合適，因為memcached僅僅支援鍵值方式的操作，沒有排序之類的功能，所以如果要用它來實現訊息佇列，則必須自己通過某個鍵來儲存陣列形式的佇列，不過這樣的話，在操作佇列的時候很容易丟失資料，比如說我們要新增乙個訊息，則需先取出現有佇列，然後把訊息儲存到佇列尾部，最後儲存佇列，單純使用memcached的話，由於我們無法保證整個過程的原子性，所以當處理若干個併發請求時，各個請求間可能會互相覆蓋，丟失資料就在所難免。另外，memcached只是記憶體鍵值快取而已，一旦宕機，資料就消失了。
memcacheq的出現解決了上面的問題，它在memcached的基礎上實現了訊息佇列，以php客戶端為例：
訊息從尾部入棧：memcache_set
訊息從頭部出棧：memcache_get
memcacheq依附於memcached之上，所以你可以通過現有的memcached工具來操作它，這無疑是它的一大優勢，但它也有乙個很大的缺點，那就是memcacheq本身的開發維護似乎並不活躍，如果遇到問題的話，你很可能需要自己動手解決。
目前看來，我更推薦下面這種解決方案，那就是redis，如果不了解，可以參考我以前的文章，表面上看，redis和memcached差不多，也是鍵值操作，但是redis本身實現了list，相關操作也可以保證是原子的，所以可以很自然的通過list來實現訊息佇列：
訊息從尾部入棧：rpush
訊息從頭部出棧：lpop
redis本身雖然是乙個新專案，但很有朝氣，開發維護也很活躍，如果你的下乙個web應用裡需要使用輕量級的訊息佇列，不妨使用它。
此外，還有不少其他的選擇可供嘗試，比如說mysql第三方的q4m引擎，通過擴充套件sql語法來操作訊息佇列，也是乙個不錯的選擇。
套用網路流行語：那些重量級軟體實現的不是你要的功能，而只是獨在高處不勝寒的寂寞，所以不必迷戀其中，它們只是傳說而已。
Web應用中的輕量級訊息佇列
web應用中為什麼會需要訊息佇列？主要原因是由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達mysql，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，我們可...
Web應用中的輕量級訊息佇列
web應用中為什麼會需要訊息佇列？主要原因是由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達mysql，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，我們可...
Web應用中的輕量級訊息佇列
web應用中為什麼會需要訊息佇列？主要原因是由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達mysql，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，我們可...