ruby-on-rails - Sidekiq 独特工作的奇怪行为

Question

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

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

问题是:每个作业在处理很长时间后(视频文件非常大)都会进入队列积压，但处理的作业大小也在增加。

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

更新:

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

Answer 1

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

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

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

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

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

sidekiq 的主要优点是它是多线程的。即便如此，25 个并发和大型视频进程可能会有点插入它。以我的经验， fork 更稳定和可移植，对应用程序的线程安全 (YMMV) 的担忧更少。

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