Sidekiq 独特作业的奇怪行为

Question

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

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

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

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

更新：

我正在运行 Puma 作为网络服务器。

Answer 1

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

我显然没有看到你的应用程序，但我敢打赌你根本不想经常处理同一个文件。我会在应用程序层控制它，并跟踪我自己的哈希键，执行类似于 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例如，在代码中，他们引入了自动过期行为，以“避免任何可能的泄漏”。（参考）如果您确实需要执行这些作业，这并不是很令人鼓舞。