我有一个运行了一段时间的 Sidekiq 作业，当我部署到 Heroku 并且该作业正在运行时，它无法在几秒钟内完成。
这很好，因为该作业被设计为能够在需要时重新运行。
问题是作业丢失（而不是放回redis并在部署后再次运行）。
我发现建议在heroku上设置:timeout: 8，我试过了，但没有效果（也试过设置为5）。
当出现异常时，我会收到错误报告，但我看不到任何错误。所以不确定是什么问题。
关于如何调试的任何提示？
【问题讨论】：
标签： ruby-on-rails ruby heroku sidekiq
这实际上是 sidekiq 的功能 - 旨在引导您走向付费专业版： http://sidekiq.org/products/pro
可靠性
更可靠的消息处理。
云环境嘈杂且不可靠。看到超时？延迟或性能的剧烈波动？ Ruby VM 崩溃或进程消失？
如果 Sidekiq 进程在处理作业时崩溃，则该作业将丢失。
如果 Sidekiq 客户端在将作业推送到 Redis 时遇到网络错误，则会引发异常并且作业未交付。
Sidekiq Pro 使用 Redis 的 RPOPLPUSH 命令确保在进程崩溃或收到 KILL 信号时不会丢失作业。
Sidekiq Pro 客户端可以承受短暂的 Redis 中断或超时。它会在出错时将作业排入本地队列，并在连接恢复后尝试交付这些作业。
Deploy 终止属于用户的所有进程，因此作业丢失。实际上你可以在那里做的事情并不多。
【讨论】：
Sidekiq 免费版会在超时后将未完成的作业推送回 Redis，默认为 8 秒。 Heroku 给一个进程 10 秒的时间来关闭。这意味着我们有 2 秒的时间将这些作业恢复到 Redis否则它们将丢失。如果您的网络速度很慢，如果 Redis 服务器正在交换等，则可能无法满足 2 秒的最后期限并且作业丢失。
您走在正确的轨道上：一个答案是降低超时时间，这样您就有更好的机会在截止日期前完成任务。但无法预测网络或交换延迟：即使 5 秒也可能不够。
在正常健康的条件下，事情应该按设计运行。保持你的机器健康（网络畅通，内存充足），基本的提取应该可以正常工作。 Sidekiq Pro 的可靠获取功能是对 Sidekiq 如何获取作业和解决所有这些问题的基本重新设计，方法是始终将作业保留在 Redis 中，这样它们就不会丢失。但它也带来了严重的权衡：它比“基本”提取更复杂、更慢且更密集 Redis。
简而言之，我不知道您为什么会失业，但请确保您的实例和 Redis 服务器运行良好且延迟较低。
https://github.com/mperham/sidekiq/wiki/Using-Redis#life-in-the-cloud
【讨论】：
正如@mike-perham 和@esse 所指出的，Sidekiq 的设计方式是由于其获取机制而可以释放工作。解决此问题的方法是：
【讨论】：