3

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

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

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

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

升级版：

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

4

1 回答 1

5

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

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

于 2012-11-16T16:31:04.690 回答