我正在构建一个类似于pingdom 的监控服务，但监控系统的不同方面并使用sidekiq 对运行良好的任务进行排队。我需要做的是安排每分钟发送一次 ping，而不是使用基于 cron 的系统，这需要每分钟启动一个新的 ruby 实例我已经使用sidetiq 的路线（注意不同的拼写与"t") 它使用 sidekiq 自己的队列来安排未来的任务。这感觉像是一个巧妙的解决方案，但我担心这可能不是最可靠的调度任务方式？如果系统出现问题（因为在某些时候不可避免），这种调度任务的方法是否会比使用基于 cron 的方法更不可靠？为什么？
谢谢
【问题讨论】：
您对系统需求的描述太短了，但我会试着猜测一下：
首先，使用 sidekiq 意味着您还需要一个 redis 实例，还意味着您需要一种方法来监控 sidekiq 进程并在出现故障时重新启动它，并且可能是 redis 服务器。
基于 cron 任务的方法要求更少，因此失败的可能性也更小。
cron 已经存在了很长时间，它经过了实战考验，非常非常可靠，但也有它的缺点。
也就是说，您可以在主/从配置中构建具有单独的 redis 实例的系统，您还可以使用 Redis sentinel 在主故障的情况下实现故障转移，在此设置上实现监控/警报系统（您可以使用来自sidekiq 作者的http://contribsys.com/inspeqtor/ 之类的超级简单的东西），您还可以在不同的机器上启动多个sidekiq 实例。
有了所有这些，您就可以拥有一个非常可靠的系统来使用 sidetiq 运行 sidekiq。
希望对你有帮助
【讨论】：