Sidekiq奇怪的独特工作行为

Question

好。我正在使用Sidekiq在后台转换视频文件。我使用sidekiq-unique-jobs gem来避免与同一个有效负载对象重复的作业。

我在没有选项的情况下运行我的sidekiq进程，并且在并发队列为25的默认队列中。

问题是：长时间处理后的每个作业（视频文件真的很大）都会进入队列积压，但处理过的作业的大小也会增加。

工作既不完整也不独特。我被卡住了。提前致谢

UPD：

我正在将Puma作为Web服务器运行。

Answer 1

尝试在没有sidekiq-unique-jobs gem的情况下运行它。无论如何，它只是保护你免受欺骗30分钟。该gem在Redis中将其hashkeys设置为在30分钟后自动过期（可配置）。 sidekiq本身将其工作设置为在24小时后在Redis中自动过期。

我显然没有看到你的应用，但我敢打赌你不想经常处理同一个文件。我会在应用程序层控制它，并跟踪我自己的hashkey做类似于unique-jobs gem正在做的事情：

hash = Digest::MD5.hexdigest(Sidekiq.dump_json(md5_arguments))

sidekiq-unique-jobs中间件也可能妨碍sidekiq知道作业是否正确完成。我敢打赌，在同样的配置中，没有很多人用长期工作来测试这个。

如果您在没有其他中间件的情况下继续看到此行为，请尝试resque。我从来没有见过这种宝石的这种行为，失败的工作在管理GUI中有一个有用的重试选项。

sidekiq的主要好处是它是多线程的。即便如此，大型视频流程的并发性可能会推动它一点点。根据我的经验，分叉更稳定，更便携，更少担心应用程序的线程安全性（YMMV）。

无论您做什么，请确保您了解这些系统在Redis中放置数据的自动过期TTL设置。工作的规模和性质意味着工作可以轻松备份24小时。这些自动删除发生在数据库层。如果作业已被自动删除，则不会对应用程序层进行回调以发出警告。例如，在sidekiq代码中，他们引入了自动过期行为以“避免任何可能的泄漏”。 （reference）如果你真的需要执行这些工作，这不是很令人鼓舞。