我最终写了我自己的图书馆,在一阵无法控制的牦牛剃须中。守护程序套件是正确的总体思路,但对于我的需求来说太重了。我不希望我的每个守护进程看起来像一个完整的 Rails 应用程序。我最终会得到至少 3 个守护进程,那将是一大堆目录。daemons gem 有一个糟糕的 API,虽然我很想将它抽象出来,但我意识到自己管理 fork 可能更容易,所以我就是这样做的。
API 如下所示:
require "rubygems"
require "chaingang"
class Worker
def setup
# Set up connections here
end
def teardown
# Tear down connections here
end
def call
# Do some work
sleep 1
end
end
ChainGang.prepare(Worker.new)
然后您只需使用包含的 rake 任务来启动/停止/重新启动或检查状态。我从 Rack playbook 中获取了一个页面:任何实现该call
方法的东西都是公平的游戏,作为 ChainGang.prepare 和 ChainGang.work 方法的参数,所以 aProc
是一个有效的工作对象。
比起使用其他东西,我花了更长的时间来构建它,但我有一个模糊的怀疑,即从长远来看它会得到回报。