Sidekiq 独特作业的奇怪行为

Question

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

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

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

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

更新：

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

Answer 1

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

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

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

sidekiq-unique-jobs 中间件也可能妨碍sidekiq 了解作业是否正确完成。我敢打赌，在您的相同配置中使用长时间运行的作业测试此功能的人并不多。

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

sidekiq 的主要好处是它是多线程的。即便如此，具有大型视频进程的 25 个并发可能会有点推动它。根据我的经验，分叉更稳定、更便携，对应用程序的线程安全 (YMMV) 的担忧更少。

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