Sidekiq与lock_expiration不按预期工作的唯一作业

Question

我对lock_expiration和sidekiq独特的工作有个问题。

gem 'sidekiq', '4.2.10'
gem 'sidekiq-cron', '1.2.0'
gem 'sidekiq-unique-jobs', '6.0.25'

有以下几个选项：

sidekiq_options queue: :medium, retry: 3, lock: :until_executed, lock_expiration: 120 * 60

当此员工已运行时：

[1] pry(main)> HardWorker.perform_async
=> 53b93f122fddbb2ebd350332267484ea

作业完成，因为执行是一个空方法。锁发生了，我在redis中看到了这个：

​

如果可用键仍然存在于redis中，即在5秒TTL过期之前。只要刷新TTL和该键，我就可以为另一个作业排队并继续这样做。但是，在5秒和该键过期后，在“存在”键过期之前，我无法对其他作业进行排队。

我希望在5秒过去之后，我能够为另一个作业排队。我非常肯定，在作业正确完成后，应移除现有键。但这种事不会发生。作业可以排队，但只能在可用密钥的TTL中排队。

我正在从一个非常老的版本升级。这是我在没有升级系统其他主要部分的情况下所能做的。

我的问题是，这是否有意的行为？基于我们已经完成的升级和配置属性的替换。它应该能像以前那样工作。也就是说，能够在当前作业完成后排起队。

假设这要么是错误，要么是有意的行为。我怎么才能有这种行为？

Answer 1

我相信您的理解是正确的，并且只要调用了worker的perform方法(基于docs中为until_executed策略描述的语义)，锁就应该被清除。如果没有发生这种情况，您可能会遇到一个bug。

然而，sidekiq-unique-jobs的6.x版本被作者描述为"the worst mistake I ever made as a software engineer" (https://github.com/mhenrixon/sidekiq-unique-jobs/issues/553#issuecomment-732719189)和"not stable" (https://github.com/mhenrixon/sidekiq-unique-jobs/issues/553#issuecomment-733151792)。我建议升级到至少7.x，然后再拔出更多的头发试图解决这个问题。

(或者，如果这是一种选择，Sidekiq提供了独特的工作支持，在我的经验中证明了它是有效的防弹功能。)