先介绍下基本概念。
我们在编写程序时，偶尔会遇到需要用到异步队列的情况。比如说，我发送一万封邮件，如果单纯使用一个for循环来发送，则执行时间要很长，要等很久才能发完，同时很容易导致阻塞、超时等问题。当邮件更多，比如一百万封的时候，问题会更加明显。这时最好的解决方案就是把这十万封邮件排队，一一发出去。这就是任务队列的概念。
并且，我们并不需要等到十万封邮件都发送完毕后才在网站前台通知用户。我们可以把邮件一入队列，就通知用户。这样，用户等待的时间就不是漫长的“发十万封邮件”的时间，而是“把十万封邮件排队”的时间。因此能明显地缩短了用户等待时间。这就是异步的概念。
HTQ ，全称 Http Task Queue ，是一个以Http方式执行异步任务的队列服务。你可以推送若干url进HTQ队列,HTQ会以Http GET 的方式访问这些url。如果url所在的脚本写上各种具体的任务操作，如发送邮件等，便可以实现异步操作了。HTQ使用node.js编写，可跟各种后台语言如PHP、java配合使用以增强异步处理能力。目前支持的队列类型有实时异步队列、定时异步队列、可变异步队列。
如果你依然对HTQ陌生，则可往下看详细的应用场景以加深了解。
1、实时异步队列
所谓实时，指的是把任务一推进队列就马上执行。一个典型的应用场景就是我们上面所说的发送邮件。邮件推送进任务队列，队列马上把它发出去。如果它推进队列后有其他邮件正在发送中，它则等待当前邮件发送完毕后才发送。
除了发邮件，我们在发文章、发微博、发评论的时候都可以用得上HTQ的实时任务队列，尤其是数量非常大的时候。比如评论用户太多，如果一瞬间让服务器处理，服务器可能因为支撑不了太高的并发从而造成阻塞。这个时候就可以让评论们进入队列再一一处理。
2、定时异步队列
定时，顾名思义，就是在特定的时间执行任务队列。这种队列服务可用于定时邮件、定时短信。需要说明的是，这里的定时，不一定是精准的定时。假如你设置了明天12点执行某个任务，那么，它在明天12点的时候将进入队列。假如队列中已经有任务在执行，那么它会等待到前面的任务完毕才执行。此时可能是12点01分钟才执行。
3、可变队列
我们推送10个任务进队列，这10个队列会反复循环地执行，并且它们的执行快慢能够根据返回情况进行调整，这就是可变队列。比如，我们做扫描监控，会反复地执行“扫描”这个任务。我们希望，在有异常情况的时候，能加快扫描的速度以便更快速地发现问题；而在没有长期异常的情况能减慢一下扫描速度以节省机器资源。
再举一个场景例子，通过API拉取微博新动态。我们网站上有10万绑定了新浪微博的用户，我们需要时常获取他们的最新动态以展示在我们的网站的用户主页上。 如果是采用定时获取动态的方式，那么，假设1分钟能获取1千个用户的动态（因为受API使用频率和网络等原因限制，我们获取不了太快。这里先假设一个数字），那么，获取完所有用户状态需要100分钟。对用户来说，他在微博更新动态后，100分钟后才显示到我们网站。这明显滞后太多。有没有办法加快点呢？此时可以使用HTQ的可变队列。可变队列会对长期没有更新动态的那部分不活跃用户进行减缓速度，减缓对他们微博的获取频率，同时加大对活跃用户的获取频率。这样，一个活跃用户更新微博后，可能10分钟就能同步到我们网站了。对于不活跃用户，可能获取时间会变长了些，但不要紧，我们愿意分配更多的资源去满足活跃用户的需求。
使用可变队列，能让我们有所侧重地使用我们的资源，以减少浪费、增加利用率。
1、安装
首先安装好node环境和redis服务，请参考这里和这里。
下载到你想要放置的目录，命令行进入该目录，执行命令：
npm install
安装完毕后，执行以下命令启动：
node htq.js
上面这种启动方式是临时运行的，关闭命令行窗口就会停止了。如果想一直在后台运行，则可：
nohup node htq.js > ~/htq.log 2>&1 &
如果想关闭退出，可运行：
killall -9 node
2、如何使用
启动后，HTQ默认监听本机的5999端口。你可以通过此端口访问HTQ的APi，以添加队列和任务。详细的API文档
你可以根据API文档来在你的项目中调用API以新建任务。官方提供了一个PHP调用的SDK（在/PHPSDK目录）。欢迎其他语言的开发者也将HTQ的API封装成其他语言的SDK
如果要修改默认端口以及默认的redis地址，可修改配置文件config.json。修改完毕需重启HTQ才能生效
1、程序安全
访问HTQ 的API时需要填写简单的token认证，认证信息在配置文件config.json里定义。为了安全起见，你可以在下载代码将token设置为其他随机数。如果你已经启动了HTQ，则需要关闭后再重启才能让新配置生效。
如果你担心直接执行url会带来安全隐患，怕自己暴露的url被外部访问，那你可以在推送进HTQ的url上带参数签名校验。然后在url触发的任务脚本里检验签名即可。
2、数据安全
HTQ使用redis来储存队列。Redis自身带有持久化功能。如另外需要对数据进行备份，则备份redis即可，不用在业务中实现数据备份。
3、正确性
HTQ能执行url，但不能保证业务上的正确。比如说HTQ确实是触发了发文章的脚本，然而这个脚步可能自身因为网络原因发布文章失败。此时应该在业务层做好相应的容错处理，比如让该url重新入队列。
