开源的任务队列服务 HTQ

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 3030 天前的主题，其中的信息可能已经有所发展或是发生改变。

一、什么是 HTQ

先介绍下基本概念。

我们在编写程序时，偶尔会遇到需要用到异步队列的情况。比如说，我发送一万封邮件，如果单纯使用一个 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 分钟就能同步到我们网站了。对于不活跃用户，可能获取时间会变长了些，但不要紧，我们愿意分配更多的资源去满足活跃用户的需求。

使用可变队列，能让我们有所侧重地使用我们的资源，以减少浪费、增加利用率。