这个，又是老王的文章，队列，确实还是需要用到的。不过，我倒真没有想过用专业的队列消息数据库等来处理。我最初只是想把一些要队列的信息用SQLITE来处理，一边是往里推，一边是往外拉。拉一条删除一条。等到数据量太大的时候，就清除掉。
老王还是有介绍的，我在PHPRPC群里也听缘起缘灭和廖羽雷他们谈过专业的队列处理，但，我目前做的事情，还是用不了专业的队列处理，所以也就没有放在心上，不过，既然老王有介绍，也可以稍看看【原本我计划做个短信定时发送也就是准备用队列处理的，但最后没做，因为139邮箱里居然有类似功能，NND，抢我饭碗】
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语法来操作消息队列，也是一个不错的选择。
套用网络流行语：那些重量级软件实现的不是你要的功能，而只是独在高处不胜寒的寂寞，所以不必迷恋其中，它们只是传说而已。
--EOF--
原文链接：http://hi.baidu.com/thinkinginlamp/blog/item/27a18202578f3d054bfb511f.html