当我在 Heroku 上发现 Appoxy SimpleWorker 时，我正要开始在我的应用上启动并运行延迟作业。
Appoxy 说它是大规模并行的，它可以上下扩展工作人员以最大限度地降低成本。但是，在我看来，使用 HireFire，delayed_job 也是如此。这是我的问题：你会选择哪个：delayed_job + HireFire 还是 SimpleWorker？（为什么？）
https://github.com/tobi/delayed_job
http://hirefireapp.com/
http://addons.heroku.com/simple_worker
我的应用目前很小——音量很小，而且应用数量在很长一段时间内应该不会特别多。
还有什么地方可以期望直接从这两种服务的创始人那里得到回复？谢谢迈克尔和特拉维斯！
【问题讨论】：
标签： ruby-on-rails ruby-on-rails-3 heroku delayed-job hirefire
嗨（这是 HireFire 的作者）
我将尝试提供一些有关服务之间差异的信息。不确定它是否对你的决定有很大帮助，但至少它是一些东西！
两种解决方案都采用不同的方法。 HireFire 仅在必要时扩展您的 Heroku 网络和工作人员测功机。您无需更改现有代码库中的任何内容，只需照常使用延迟作业。您不必为单独的环境/平台发送/编写代码，因为它在部署时在 Heroku 平台上编译为 slug，当新的 web 或 worker dyno 启动时，slug 会立即使用并运行（包含您的所有ENV 变量/设置。
与 SimpleWorker 相比，HireFire 的缺点是 HireFire 是 Heroku 特有的。因此，如果您曾经从 Heroku 切换到例如 EngineYard 或 VPS/Dedicated 盒子，那么 HireFire 将无法工作，但 SimpleWorker 会因为它没有严格绑定到 Heroku。虽然，在非 PaaS 平台上托管可能非常便宜（相比之下），因此不一定需要或根本不需要自动缩放。
在开发 HireFire 之前，我一直是 SimpleWorker 的客户，但我个人不喜欢的是，我必须将部分代码库推送到 SimpleWorker，然后加载到我的 Rails 环境中，然后从他们的数据库重新连接到数据库服务器位置，并且每次我想将工作发送到云时也会执行 API 请求（尽管现在可能已经改变了，所以我鼓励你自己检查一下，也许它不是对你和我来说都是一个大问题）。对我来说，每次我想添加新的作业类并且必须将所有单独的代码从我的应用程序和我的 gem 加载到作业类文件本身时，这简直是太多的麻烦/试验和错误，同时运行 @987654322 @ 或 heroku ps:scale worker=2 会立即启动一两个工作人员并开始处理对我的代码库的零修改，这与我在本地运行它时完全相同，因为我的整个应用程序已经在 Heroku 上编译为一个 slug 它只是使用它，包括我的 ENV 变量和其他设置/插件，它会快速启动。
使用 HireFire，您只需将 the hirefireapp gem 添加到您的 Gemfile，将您的 Heroku 帐户/应用程序添加到 HireFire Web 界面，自定义您的扩展需求，将您的应用程序部署到 Heroku，就是这样。您的应用程序将被持续监控和管理/调整（每分钟或更短时间）。
HireFire 没有带有工作表及其状态（运行/完成/失败/等）的流畅界面（它确实概述了每个应用程序的当前网络/工作人员测功机数量和排队工作当然，以及可自定义的缩放设置），尽管提供此类功能确实是工作库的工作。据我所知，Delayed Job 有一个或两个你可以使用的小管理界面（开源），它们与 HireFire 无关。因为 SimpleWorker 既是一个托管服务，又是一个工作库，它们还为您提供了一个 Web 界面。
HireFire 也能够扩展您的网络测功机，而不仅仅是您的工作人员测功机。
这两种服务都能够并行处理大量作业，因为据我了解，Heroku 和 SimpleWorker 都是按比例分配的。因此，无论您是在 6 秒内旋转 10 个工人测功机，还是在 60 秒内旋转 1 个，都不会（或几乎没有）成本。
我在自己发布 HireFire 后没有使用过 SimpleWorker，那是很久以前的事了，所以我不确定 SimpleWorker 这些天还提供了什么，或者他们是否从那时起简化了流程，所以我不确定上述是否我所做的声明此时仍然有效。
希望这会有所帮助！
【讨论】：
嗨（SimpleWorker 的创始人），
Michael 总结得很好，但我将添加一些 Heroku Workers 和 SimpleWorker 之间的区别，不一定是 HireFire。
缺点是使用 SimpleWorker 需要更多考虑，因为它没有运行完整的 Rails 环境。您必须将您的工作人员视为在不同系统（它们是）上运行的独立实体。对于简单的事情，比如在后台发送电子邮件或从前端卸载一些东西，Heroku Workers 可能是一个不错的选择。如果您执行任何大型批处理作业、调度、长时间运行的作业，想要更多地了解您的作业等，那么您可能想尝试一下 SimpleWorker。
顺便说一句，我们最近发布了一些新视频，以便您了解它的工作原理和易用性：http://www.simpleworker.com/how_it_works/videos
希望对您有所帮助！如果您对 SimpleWorker 有任何疑问，请随时问我。
【讨论】：
$ heroku ps:scale worker=100 会将您的工人数量设置为100。 （这适用于他们的新“Celadon Cedar”堆栈，尚未使用之前的堆栈进行测试：“Badious Bamboo”）
我使用延迟作业，然后使用 rake 任务根据我的数据库中是否有任何延迟作业来扩展我的 heroku 工作人员：
namespace :heroku do
namespace :workers do
desc "stop heroku workers"
task :stop do
p ['stopping workers for', CONFIG['heroku_project']]
Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 0)
end
desc "start heroku workers"
task :start do
p ['starting workers for', CONFIG['heroku_project']]
Heroku::Client.new(ENV['HEROKU_EMAIL'], ENV['HEROKU_PASSWORD']).set_workers(CONFIG['heroku_project'], 1)
end
desc "starts workers if the are items in the queue, otherwise, stops them."
task :check_queue => :environment do
p ["Env: ", Rails.env]
count = DelayedJob.find_pending.count
p ['Pending delayed jobs: ', count]
if count > 0
Rake::Task['heroku:workers:start'].invoke
else
Rake::Task['heroku:workers:stop'].invoke
end
end
end
end
使用调度程序插件，我可以每 10 分钟检查一次我的工作人员，以降低成本。
我喜欢这个解决方案，因为我可以使用 DelayedJob（我很熟悉），而不是使用另一个插件或第三方，我只需要一个简单的 rake 任务来限制 Heroku 的成本，并且基本上只为我支付的费用使用。
【讨论】：