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