HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式、持久化消息队列。它利用HTable存储消息数据，借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储，并基于HBase Client API封装了HQueue Client API用于消息存取。 HQueue可以有效使用在需要存储时间序列数据、作为MapReduce Job和iStream等输入、输出供上下游共享数据等场合。

    socket 底层有一个 poll 的 api ，通过 epoll 或 kqueue 或 select 取得一系列的事件。用 lua 怎么封装它呢?一个比较直接的想法是注入一个 callback function ，对于每个事件回调一个 lua 函数。但这容易引起许多复杂的问题。因为回调函数很不可控，内部可能抛出异常，也可能引起函数重入，或是做了一些你不喜欢去做的事情。

    

最近忙着用Redis实现一个消息通知系统，今天大概总结了一下技术细节，其中演示代码如果没有特殊说明，使用的都是PhpRedis扩展来实现的。

    RabbitMQ大家应该不陌生，著名的消息队列嘛。可惜我最近才听说它的大名，了解之后不禁惊呼，世界上居然还有这种东西！立刻觉得手里有了锤子，就看什么都是钉子了，主网站不愿意干的操作统统扔给RabbitMQ去做吧 言归正传，先介绍一下这篇文章的应用场景吧。我们知道大型网站的性能非常重要，然而有时不得不做一些相当耗时的操作。比如SNS网站的“新鲜事儿”系统，我发帖之后，会给所有关注我的人推送一条通知。乍一看没什么难的...

    我花了一周的时间评估比较了一下各种消息队列产品，非常的有趣。我做这个事的动机是因为一个客户有一个很高性能需求。他们的消息信息突破了1百万个并发。目前他们使用的是SQL server，并不理想，我建议他们使用消息队列服务器。 为了对一些相似的候选产品获得一个全面的但是粗浅的性能上的了解，我们它们放在一起做了个测试。我让每个消息产品各发送和接受1百万千条1K的消息...

    经过同事们的一番努力，终于把搜索更新改为基于MQ的方式了，大家(特别是增禄和大庆)辛苦了。搜索更新早就想改了，因为种种限制，无法实施。这些限制如下：一）手机之家采用混合编程(主要是PHP+JAVA)。二）JAVA调用PHP显然不是好方法。三）用PHP做异步触发很困难。四）用PHP写驻留程序很困难。五）要让PHP在消费消息失败时回滚很困难。六）基于这些限制，DAL1.0最后用PHP和数据库实现了一个不太可靠的消息队列。